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ABSTRACT 


This  document  constitutes  a  representative  survey  of  twenty  computer 
software  systems  which  have  been  developed  within  the  last  decade. 

The  surveyed  systems  have  been  grouped  into  six  major  categories: 

(1)-  general  purpose  programming  and  executive  systems;  (2)  functional 
systems;  (3)  man-machine  interface  systems;  (4)  special  purpose 
programming  systems;  (5)  time-sharing  systems;  (6)  generalized 
data  management  systems. 

Each  system  discussed  within  these  categories  exhibits  a  particular 
feature  or  set  of  features  which  constitutes  a  distinct  contribution  to 
the  effort  to  produce  more  general,  more  flexible  and  less  job  depen¬ 
dent  systems  which  can  be  conveniently  operated  by  a  user. 

The  survey  notes  that  to  date  efforts  to  develop  these  features  into 
integrated  computer  systems  and  sub-systems  exist  only  on  a  small 
scale  and  in  only  a  small  number  of  laboratories  scattered  across 
the  country.  In  view  of  the  many  potential  applications  of  such 
integrated,  generalized  computer  systems,  especially  in  military 
environments,  the  survey  concludes  that  the  time  is  ripe  for  a  tech¬ 
nical  program  designed  to  demonstrate  the  feasibility  of  generalized 
computer  systems  and  sub-systems  in  the  solving  of  traditional  data 
processing  problems. 
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INTRODUCTION 


Computer  programs  are  detailed  instructions  written  to  adapt  a  completely 
general  purpose  machine  to  a  specific  problem  or  application.  If  an 
engineer  has  a  mathematical  problem  to  be  solved,  he  must  write  a  sequence 
of  instructions  to  control  the  arithmetic  and  logical  circuitry  of  the  machine, 
thus  formulating  a  specific  problem  solving  procedure.  This  sequence  of 
instructions  constitutes  a  program  which  must  be  executed  or  run  on  the 
machine  to  obtain  an  answer.  Similarly,  if  a  manager  wishes  a  report  on 
inventory  contair:ng  extractions  from  several  files  of  data  in  memory,  he,  too, 
must  write  down  a  sequence  of  instructions  to  control  the  same  arithmetic 
and  logical  circuitry  of  the  machine  to  search  tapes,  retrieve  data,  format 
it  and  activate  printout  devices  to  obtain  the  desired  result.  Next,  this 
program  must  be  executed. 

There  is  another  type  of  computer  program,  however.  Designed  and  writ¬ 
ten  by  computer  specialists,  this  type  of  program,  often  called  "software,  " 
is  intended  to  provide  the  engineer  or  the  manager  with  more  than  just  an 
empty  machine.  Software  programs  are  tools  in  the  form  of  programs  which 
the  engineer  or  the  manager  can  use  for  building,  controlling  and  modifying 
the  complex  sequences  of  problem  solving  procedures  required  in  his  soph¬ 
isticated  computer  applications. 

Clearly,  then,  the  motivation  for  the  development  of  software  and,  indeed, 
its  contributions  have  been: 

(1)  Improving  the  ease  with  which  application  programs  can  be 
written  or  modified  and  users*  problems  solved. 

(2)  Reducing  the  cost  of  constructing,  modifying  and  executing 
application  programs  and  solving  users*  problems. 

Following  is  a  review  of  a  representative  though  by  no  means  exhaustive 
cross-section  of  the  major  software  developments  that  have  been  achieved 
recently.  The  systems  discussed  are  sufficiently  contemporary  to  be 
regarded  as  exemplifying  current  technology  and  sufficiently  sophisticated  to 
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be  regarded  as  advanced  state-of-the  art.  For  some  readers  there  will  be 
no  mention  of  some  systems  and  too  little  mention  of  others.  This  is  due 
largely  to  time,  space  and  available  material  limitations. 

The  twenty-plus  systems  under  review  have  been  grouped  into  five  separate 
categories,  and  a  sixth  special  category,  the  significance  of  which  is  to 
be  seen  in  the  light  of  the  first  five  categories.  These  categories  are: 

(1)  general  purpose  programming  and  executive  systems,  (2)  functional 
systems,  (3)  man-machine  interface  systems,  (4)  special  purpose  systems, 

(5)  time-sharing  systems,  and  (6)  generalized  data  management  systems. 

A  person  familiar  with  these  systems  will  notice  a  discrepancy  in  the 
groupings.  Thus  COLINGO,  listed  under  {?.),  functional  systems,  could 
just  as  easily  have  been  included  under  (3),  man-machine  interface  systems. 
Similarly,  BASEBALL,  listed  under  (3),  man-machine  interface  systems, 
could  have  been  included  under  (2)  functional  systems.  But  these  discrepancies 
are  more  apparent  than  real. 

To  begin  with,  the  categories  identified  in  this  document  do  not  refer  to 
characteristics  which  the  systems  under  one  category  possess  and  which 
all  other  systems  do  not  possess.  Rather,  the  categories  represent  various 
perspectives,  or  points  of  view,  which  system  designers  chose  to  emphasize 
in  the  design  of  their  systems. 

Thus,  the  categories  which  have  been  established  are  intended  to  indicate 
a  designer’s  preference- with  respect  to  that  which  is  of  primary  importance 
in  the  construction  of  automated  data  processing  systems.  In  this  light, 
then,  CL-II,  AOSP,  DODDAC,  NECPA,  OASIS,  and  INTIPS,  all  examples 
of  general  purpose  systems,  have  been  the  products  of  designers  v.ho  have 
determined  that  extended  and  sophisticated  programming,  executive,  and 
utility  systems  are  the  key  to  more  flexible,  more  powerful  computer-based 
systems.  In  particular,  the  design  of  general  purpose  executive  systems  is 
accomplished  without  reference  to  a  specific  system  or  application.  In  fact, 
taking  into  account  the  specific  requirements  of  a  particular  application, 
such  as  Hq  USAF  or  Hq  USSTRICOM,  would  defeat  the  purpose  of  general 
purpose  systems  which  are  intended  to  provide  an  integrated  programming 
tool  that  can  be  easily  used  by  and,  therefore,  of  assistance  to  programmers 
in  the  process  of  designing,  preparing,  and  executing  specific  sets  of  pro¬ 
grams  required  by  specific  applications. 

In  contrast  to  the  general  purpose  point  of  view  which  emphasizes  general 
programming  tools  quite  apart  from  the  requirements  of  a  specific  application, 
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there  is  the  category  of  functional  systems  which  includes  the  COLINGO, 
NAVCOSS;.CT,  TUFF-TUG,  FICEUR,  473L,  and  ACSI-MATIC  systems. 

These  systems  have  been  designed  from  a  point  of  view  that  stresses  a 
particular  function,  e.  g.  ,  information  retrieval.  In  this  case  a  system 
must  be  primarily  constructed  around  the  function  which  it  will  be  called 
upon  to  exercise  more  often  than  any  other  function.  This  functional 
approach,  which  by  no  means  ignores  the  advantages  of  general  purpose 
program  design,  chooses  to  measure  all  its  design  decisions  in  the  final 
analysis,  not  by  how  much  general-purpose  capability  each  alternative  might 
achieve  for  the  system,  but  by  how  much  the  design  will  contribute  to  the 
major  function  for  which  the  system  is  being  implemented. 

In  contrast,  then,  to  the  general  purpose  and  the  functional  point  of  view, 
there  is  the  perspective  v/hich  stresses  the  development  of  the  man/machine 
interface  as  being  of  primary,  but  by  no  means  exclusive,  importance  in 
system  design.  This  category  includes  SKETCHPAD,  BASEBALL,  DEACON, 
JOSS,  and  Culler-Fried.  Each  of  these  systems  has  introduced  a  new 

dimension  along  which  man  and  machine  may  interact.  With  SKETCHPAD 
the  dimension  is  graphical;  with  JOSS,  the  dimension  is  easy  mathematical 
computation  for  scientific  and  engineering  users;  with  Culler-Fried,  the 
dimension  is  push-button  representation  of  operator/operand  functions 
characteristic  of  mathematical  problem  formulation.  Not  all  of  these  systems 
have  been  constructed  with  a  specific  job  function  in  mind.  But  each  has 
emphasized  the  necessity  for  making  the  man/machine  interface  as  flexible 
and  unconstrained  as  possible  in  the  performance  of  some  job,  real  or 
potential. 

In  contrast  to  the  three  aforementioned  approaches,  there  exists  yet  another 
one  to  computer-based  system  design.  From  this  point  of  view  emphasis 
is  placed  on  the  development  of  a  particular  problem-oriented  language 
which  is  tailor-made  to  some  specific  problem  area;  that  is,  the  development 
of  a  language  which  is  easy  for  the  computer  to  manipulate  and  which  is  simul¬ 
taneously  much  like  the  specialized  language  normally  used  by  the  potential 
user.  The  point  of  view  represented  by  the  problem-oriented  language  designer 
is  quite  similar  to  the  man-machine  interface  designer  but  with  one  important 
exception.  The  latter  wants  to  provide  a  tool  which  can  be  used  over  a  large 
class  of  problem  areas.  Thus,  a  graphical  technique  can  be  used  not  only 
in  solving  engineering  problems,  but  also  in  solving  artistic,  mechanical 
drawing,  mathematical  and  geometric  problems  as  well.  On  the  other  hand, 
the  special  purpose  problem-oriented  language  is  one  which  can  be  used  in 
only  one  specific  problem  area,  It  cannot  be  generalized  and  for  that  reason, 
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it  can  pay  a  great  deal  of  attention  to  providing  a  specific  problem-oriented 
language  which  maximizes  convenience  for  some  practitioner  in  a  specific 
area.  STRESS,  a  language  for  expressing  structural  engineering  problems 
and  COGO,  a  language  for  civil  engineering  problems,  are  two  examples  of 
this  approach  to  system  design. 

A  fifth  area  approaches  the  problem  of  system  design  from  a  point  of  view 
which  is  quite  different  from  all  of  the  above.  This  point  of  view,  regard¬ 
less  of  whether  the  computer  has  been  endowed  with  general  purpose  systems, 
functional  systems,  or  special  purpose  systems,  provides  the  computer  with 
the  ability  to  be  accessed  simultaneously  by  a  large  number  of  separate 
and  distinct  users.  This  perspective  on  computer-based  system  design  has 
been  labelled  the  "time-sharing"  perspective.  Its  proponents  view  the  time- 
shared  computer  as  a  kind  of  public  utility  from  which  any  user  can  draw 
whatever  computational  power  he  might  need  at  any  time  without  delay  or 
difficulty.  In  one  sense  this  perspective  differs  quite  radically  from  the 
other  four  because  it  is  not  concerned  primarily  with  the  various  ways  in 
which  computational  power  can  be  increased  or  tailored  to  a  specific 
user. 

It  was  previously  mentioned  that  the  sixth  category,  generalized  data  manage¬ 
ment  systems,  could  best  be  understood  in  the  light  of  the  preceding  five 
because  this  category  views  the  design  of  computer-based  systems  as  a 
problem  in  the  speedy  implementation  in  a  given  system  application  of  as 
many  of  the  features  of  the  preceding  categories  as  are  relevant  and,  indeed, 
possible.  Thus,  in  this  category,  the  designer  is  concerned  with  emphasizing 
general  purpose  programming  as  well  as  job  specific  programming,  and 
user-on-line  techniques  as  well  as  special  purpose  languages,  and,  if  possible, 
making  the  resultant  design  time-sharing.  Two  systems  represent  an  attempt 
to  exploit  all  of  these  categories,  viz.  ,  Advanced  Data  Management  (ADAM) 
and  Language  Used  to  Communicate  Information  System  Design  (LUCID). 

Nothing  has  yet  been  said  about  the  motivation  behind  each  of  the  perspectives 
cited  above.  There  are,  of  course,  several  motivations,  ranging  from 
personal  biases,  to  the  special  circumstances  of  a  specific  environment,  to 
the  exigencies  of  time,  money,  and  personnel,  to  the  special  talents  of  a 
specific  designer  or  user.  With  respect  to  the  category  of  generalized  data 
management  systems,  for  example,  one  quite  clear  motivation  has  been 
economics,  since  the  use  of  these  systems  as  test  vehicles  for  complex 
computer  application  obviates  the  need  for  constructing  expensive  prototype 
models.  This  ana  many  other  reasons  no  doubt  inspired  the  various  points  of 
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view  exemplified  in  the  following  discussions.  Regardless  of  motivation, 
however,  these  points  of  view  stand  as  alternatives  to  the  problem  of  the 
economic  and  effective  use  of  digital  computers.  Moreover,  the  specific 
systems  discussed  attest  to  the  success  of  each  of  these  points  of  view  and 
strongly  suggest  that  the  current  state-of-the-art  in  software  is  sufficiently 
advanced  to  countenance  further  development  in  the  exploitation  of  many,  if 
not  all,  of  these  techniques  into  effective  operational  systems  and  sub¬ 
systems. 
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NOTE 


The  compilers  of  this  survey  have  taken  the  liberty  of  quoting  extensively 
from  the  published  material  referenced  in  the  Bibliography.  Where 
accurate  descriptions  of  the  systems  are  given,  credit  is  due  the  designers 
themselves  and  their  writing  staffs.  Where  errors  occur,  the  compilers 
of  this  volume  take  full  responsibility. 

In  the  following  six  sections,  the  order  in  which  the  systems  are  presented 
was  established  on  heuristic  grounds,  and  no  evaluational  judgment  is 
intended. 
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PART  I.  GENERAL  PURPOSE  PROGRAMMING  AND  EXECUTIVE  SYSTEMS 


In  this  section  those  systems  which  have  been  chosen  to  emphasize  general¬ 
ized  programming  techniques  are  reviewed.  The  fundamental  strategy 
behind  this  approach  to  computer  application  takes  cognizance  of  the  fact 
that  users  of  many  computer  systems  are  not  only  people,  but  also  other 
programs.  It,  therefore,  addresses  itself  to  those  inter-facing  problems 
which  occur  between  programs,  both  system  and  user.  Hence,  generalized 
programming  techniques  attempt  to  provide  linkages  between  system  and 
user  programs,  without  reference  to  specific  systems  or  users.  Similarly, 
generalized  programming  techniques  attempt  to  anticipate  the  numerous 
housekeeping  functions  required  by  complex  program  configurations, 
regardless  of  [the  content  of  particular  programs.  Thus,  the  core  of  general 
ized  programming  techniques  is  the  realization  that  computers  can  be 
endowed  with  greater  power,  flexibility,  and  generality  by  providing  them 
with  programs  capable  of  manipulating  other  programs  in  the  same  way  that 
more  conventional  programs  merely  manipulate  data.  The  six  systems  dis¬ 
cussed  in  this  section  exemplify  this  strategy. 

A.  CL-II  PROGRAMMING  SYSTEM 

The  CL-II  Programming  System  is  an  integrated  collection  of  computer 
programs  which  provides  assistance  to  the  user  of  a  large-scale  digital 
computer  in  preparing  and  executing  programs.  The  system  has  been  devel¬ 
oped  by  Computer  Associates,  Inc.  for  the  IBM-7090  (94)  computer  in 
response  to  a  need  for: 

(1)  A' comprehensive  programming  environment  within  which  a 
large  group  of  programmers  can  efficiently  attack  and  solve 
problems  involving  large  programming  efforts. 

(2)  Efficient  utilization  of  computer  hardware. 

(3)  Minimization  of  the  cost  of  modification  and  extensions  of 
extant  programs. 
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(4)  A  system  which  evolves  in  accordance  with  the  needs  of 
particular  users. 

Previous  attempts  at  automatically  linking  and  operating  programs  for  the 
convenience  of  the  programmer  had  been  limited  to  compile  and  load  time 
linkages  and  to  programming  some  of  the  computer  operators  functions 
into  the  monitor  system.  This  necessitated  the  programmer’s  considering 
his  program  subject  to  the  framework  of  the  basic  computer  hardware. 

Under  the  circumstances,  each  programmer  must  repeatedly  be  concerned 
with  various  difficulties  of  assembling  and  operating  programs  when  these 
difficulties  have  little  relation  to  the  problems  his  programs  are  devised 
to  solve.  Further,  the  operating  or  monitor  system  can  do  little  more  toward 
improving  overall  machine  efficiency  than  reducing  job  set-up  time.  The 
CL-II  Programming  System  was  designed  to  provide  a  more  convenient  and 
natural  framework  than  the  basic  computer  for  the  construction  and  execu¬ 
tion  of  programs.  The  design  of  the  CL-II  System  was  guided  by  the 
following  considerations: 

(1)  The  system  will  provide  mechanisms  for  linking  programs  to 
data,  hardware  components,  or  other  programs.  These  mechan¬ 
isms  will  be  such  that  they  can  be  employed  at  any  time  in  the 
process  of  defining,  loading,  or  running  a  program. 

(2)  The  system  will  have  means  for  controlling  the  simultaneous 
execution  of  a  number  of  programs. 

(3)  The  system  will  have  no  built-in  assumptions  about  job 
scheduling.  Thus,  there  will  be  no  fixed  "job  monitor"  or 
"executive";  rather,  any  program  will  be  able  to  perform 
monitoring  functions. 

(4)  The  system  will  have  means  for  creating,  maintaining,  and 
gaining  access  to  "files"  of  programs,  data,  and  descriptions 
of  data. 

(5)  The  system  will  have  means  for  generating  the  code  for  acces¬ 
sing  elements  of  data  sets  or  programs  from  the  information 
contained  in  a  description  of  that  data  set  or  program. 

In  the  light  of  these  considerations,  the  CL-II  System  was  endowed  with  the 
following  characteristics: 
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(1)  Once  defined  to  the  system,  a  program  is  essentially  an  exten¬ 
sion  of  the  system  itself  in  the  sense  that  it  can  generally  be 
called  by  any  other  program  in  the  system  at  any  time.  This 
is  true  not  only  of  "user"  programs;  but  of  "system"  programs 
as  well. 

(2)  A  change  in  the  structure  of  a  data  set  or  program  requires  at 
most  a  recompilation  of  programs  referencing  that  data  set  or 
program  in  order  that  all  accesses  be  correct;  i.  e.  ,  no  changes 
are  required  in  source  programs  to  reflect  changes  in  the 
structure  of  data  or  programs  they  use. 

(3)  The  addition  or  deletion  of  types  of  input/output  devices  or  the 
addition  or  deletion  of  a  number  of  units  of  a  given  type  need 
have  no  effect  on  many  user  programs. 

(4)  The  "kinds"  of  problems  amenable  to  the  system  include: 
sequences  of  small  jobs  (the  kind  of  problem  acceptable  to  conven¬ 
tional  operating  systems);  large  production  programs  involving 
considerable  segmentation,  program  and  data  overlay,  and  the 
like  (such  as  large  scale  simulation  models);  "command  and 
control"  type  programs;  and  "time-shared"  programs. 

The  CL-II  System  went  through  three  stages  of  construction:  Primary  CL-II, 
Basic  CL-II,  and  the  CL-II  System  or,  simply,  CL-II.  Roughly,  Primary 
CL-II  consists  of  the  basic  programmatic  extensions  to  the  computer  hard¬ 
ware  which  form  an  "extended  machine"  with  which  the  programmer  deals. 
Basic  CL-II  is  Primary  CL-II  to  which  has  been  appended  a  sufficient  num¬ 
ber  of  "system  programs"  (compilers,  assemblers,  dumps,  monitors,  and 
the  like)  to  make  the  system  easy  to  use  for  implementing  user  programs. 

The  CL-II  System  is  then  Basic  CL-II  plus  the  collection  of  user  programs 
available  at  any  time. 

Primary  CL-II  performs  certain  basic  functions.  At  any  time  during  the  oper 
ation  of  CL-II,  there  are  one  or  more  programs  in  high  speed  memory 
which  may  be  operating  in  parallel.  With  each  program  is  associated  a 
priority  number.  Each  program  has  one  or  more  paths  which  may  be  opera¬ 
ting  (i.  e.  ,  the  computer  is  currently  sequencing  through  the  instructions 
comprising  that  path),  is  ready  to  operate,  or  is  waiting.  There  are  avail¬ 
able  to  the  system  one  or  more  files  from  which  programs  and  data  can  be 
obtained  by  name. 
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Whenever  there  is  an  available  control  element  of  the  computer  which  can  be 
assigned  to  a  program,  it  is  put  to  work  on  the  first  ready  path  of  the  high¬ 
est  priority  program  which  contains  any  ready  paths.  Thus,  the  scheduling 
which  is  built  into  CL-1I  is  extremely  simple.  It  should  be  noted  that  the 
scheduling  of  programs  does  not  derive  from  the  system  itself  but  rather 
from  priorities  determined  through  the  interaction  of  the  user  programs 
with  each  other  and  with  the  system. 

The  collection  of  "instructions"  which  can  comprise  the  programs  operating 
within  CL-II  includes  all  the  instructions,  plus  a  collection  of  "system  macros" 
provided  by  Primary  CL-U  These  system  macros  include  the  following: 

(1)  Mount  a  tape. 

(2)  Demount  a  tape. 

(3)  Assign  a  peripheral  device. 

(4)  Read,  write,  or  position  a  peripheral  device. 

(5)  Allocate  a  block  of  high  speed  memory. 

(6)  Input  or  output  data. 

(7)  Start  a  path. 

(8)  End  a  path. 

(9)  Establish  a  program  or  data  set. 

(10)  Execute  a  program  in  line  or  in  parallel. 

(11)  Await  an  input,  output,  path  completion,  establish  operation, 
tape  mounting,  etc. 

(12)  Release  a  program  or  data  set. 

(13)  Start  a  program. 

While  certain  of  these  macros  are  related  to  functions  provided  by  conven¬ 
tional  utility  systems,  the  majority  is  not.  The  "establish"  macro  is  the 
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heart  of  CL-I1.  Basically,  the  establish  macro  procures  a  program  from  the 
file,  allocates  sufficient  space  for  it,  brings  it  into  high  speed  memory,  and 
performs  all  manipulations  (e.  g.  ,  fixing  absolute  addresses,  etc.)  necessary 
to  prepare  the  program  for  execution  in  the  memory  locations  to  which  it 
is  allocated. 

When  a  program  has  been  established,  it  can  be  called  by  the  program  which 
established  it.  This  call  can  cause  the  program  to  be  executed  as  an  in-line 
subroutine,  or  as  a  completely  independent  program  (in  parallel  with  the 
program  calling). 

Any  program  which  has  requested  that  the  system  perform  some  activity 
such  as  input,  output,  establish  a  program,  execute  a  program,  start  a  path, 
mount  a  tape,  etc.  ,  can  at  some  later  time  "await"  the  completion  of  the 
activity.  If  the  activity  indicated  is  not  complete,  then  the  path  containing 
the  "await"  is  placed  in  waiting  status  and  it  is  arranged  so  the  completion  of 
the  activity  indicated  will  automatically  place  that  path  in  ready  status. 

In  order  for  the  user  to  effectively  use  CL-II,  there  is  a  collection  of 
"system"  programs  which  are  always  available  to  Primary  CL-II  on  a  "system 
file.  "  Primary  CL-II,  to  which  is  attached  this  system  file,  is  called  Basic 
CL-II.  The  system  programs  in  Basic  CL-II  include  the  following: 

(1)  Sequential  Job  Monitor 

(2)  Data  Description  Translator 

(3)  Compiler  for  (extensions  of)  Language  L  and  JOVIAL 

(4)  Compiler  Generator  System 

(5)  Data  Input/Output  Processor  Formatted  Data 

(6)  Miscellaneous  Service  Programs 

A  very  brief  description  of  these  system  programs  follows: 

1.  Sequential  Job  Monitor 

The  job  monitor  initial  y  available  in  CL-II  is  a  reasonably  standard  sequen¬ 
tial  job  monitor.  One  can,  in  a  straight-forward  way,  call  for  the  input  and 


filing  of  data  descriptions,  input  and  filing  of  instances  of  data  sets,  compila¬ 
tion  and  filing  of  programs,  output  of  instances  of  data  sets,  and  construction 
and  execution  of  collections  of  programs. 

2.  Data  Description  Translator 

A  data  description  in  CL-II  is  provided  by  an  instance  of  the  data  set  ODES 
(Object  DEScriptor).  The  object  descriptor  for  a  specific  data  set  contains 
a  complete  description  of  all  of  the  elements  of  the  data  set,  including 
names,  types,  and  mapping  functions  for  all  the  various  representations 
of  the  data  set  which  may  occur  (internal  memory,  punched  cards,  magne¬ 
tic  tape,  and  so  on).  In  addition,  it  includes  the  specification  of  the  compo¬ 
sition  of  (collections  of)  data  elements  into  large  elements,  resulting  finally 
in  the  complete  data  set. 

3.  Compiler 

The  compiler  in  the  CL-II  System  is  general  purpose,  table-driven,  and  has 
the  ability  to  generate  efficient  code.  By  supplying  appropriate  tables,  con¬ 
trol  is  obtained  over  (1)  the  language  to  be  compiled,  (2)  the  amount  of  con¬ 
text  searching  preliminary  to  code  generation,  and  (3)  the  specific  machine 
code  to  be  generated  corresponding  to  any  input  or  sub- statement.  Thus, 
modification  of  the  input  language  or  accommodation  of  a  completely  new 
language  is  handled  by  modification  of  tables  rather  than  by  rebuilding  all 
or  part  of  the  compiler.  Similarly,  "tuning"  the  generated  code  or  allowing 
for  "quir.k-and-dirty"  code  to  be  generated  under  certain  circumstances  is 
controlled  through  modifications  of  the  tables. 

Initially,  the  languages  which  are  accommodated  in  CL-II  are  L0,  the  alge¬ 
braic  language  available  in  the  CL-I  System,  and  JOVIAL.  Actually,  the 
versions  of  L0  and  JOVIAL  are  somewhat  extended  versions  in  the  sense 
that  they  are  able  to  reference  elements  of  any  type  of  data  structures  for 
which  ODES  descriptions  are  available  in  the  files. 

4.  Compiler  Generator  System 

The  compiler  generator  system  is  a  collection  of  programs  (several  of  which 
are  also  a  part  of  the  compiler  itself)  and  data  sets  which  can  produce  the 
tables  required  to  "drive"  the  compiler  from  three  sets  of  specifications: 

(1)  the  syntactic  structure  of  a  programming  language  to  be  translated  by  the 
compiler;  (2)  the  "generation  strategy"  and  context  inspection  of  syntactically 


12 


analyzed  statements  in  the  programming  language;  and  (3)  the  rules  for  the 
selection  of  specific  fragments  of  machine  code  corresponding  to  state* 
ments  or  substatements  in  the  programming  language  being  translated. 

5.  Data  Input /Output 

Given  the  description  of  a  data  set  (the  ODES  for  that  data  set),  the  data 
input  processor  in  CL-II  will  input,  edit,  and  convert  an  instance  of  the 
data  set  resulting  in  an  internal  copy  which  is  in  correct  format  for  filing 
the  data  set  and/or  "handling"  it  to  a  user  program  for  immediate  proces¬ 
sing.  The  formats  in  which  data  can  be  represented  on  external  media 
such  as  cards  are  very  general.  For  integers  floating-point  numbers, 
and  scaled  fixed-point  numbers  these  formats  include  the  designation  of 
fixed  or  free  field,  inclusion  of  signs,  decimal  points,  exponents,  and  so  on. 
The  data  input  processor  also  has  means  for  checking  the  adequacy  of  the 
data  being  input  as  to  format,  size  constraints,  duplication,  missing  values, 
etc. 

Similarly,  given  an  ODES  and  an  instance  of  the  data  set  described  by  the 
ODES  the  data  output  processor  can  output  the  data  set  in  appropriate  for¬ 
mats.  Special  headings  can  also  be  supplied. 

6.  Miscellaneous  Service  Programs 

There  is  a  collection  of  service  programs  available  to  help  the  programmer 
in  debugging  his  programs  in  CL-II.  These  include: 

(1)  Dump  programs,  which  can  be  called  to  produce  octal  and/or 
symbolic  dumps  of  specific  programs  or  data  sets  in  memory, 
optionally  including  a  "road  map"  of  all  programs  and  data  sets 
which  are  currently  occupying  memory. 

(2)  Octal  correction  programs,  which  load  corrections  into  programs 
prior  to  their  being  run. 

(3)  Symbolic  correction  programs,  which  load  corrections  repre¬ 
sented  symbolically  into  programs  prior  to  their  being  executed 
and/or  into  their  file  copies. 

As  previously  mentioned,  the  CL-II  System  is  the  union  of  Basic  CL-II  and 
the  collection  of  user  programs  developed  within  the  system.  Thus,  CL-II 
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is  fundamentally  intended  to  evolve  with  the  construction  of  user  programs 
and  will  undoubtedly  take  on  different  characteristics  with  different  collec¬ 
tions  of  users. 

The  CL-I1  System  contributes  to  generalized  data  management  systems  in 
that  it  provides  a  general-purpose  programming  environment  in  which  the 
programmer  is  freed  from  concern  with  many  aspects  of  programming  not 
connected  with  his  problem. 

It,  of  course,  is  not  fundamentally  problem-oriented  in  the  user  sense,  but 
facilitates  the  development  of  application  solutions  within  its  framework. 

B.  AUTOMATIC  OPERATING  AND  SCHEDULING  PROGRAM  (AOSPJ 

The  Automatic  Operating  and  Scheduling  Program  (AOSP)  for  the  Burroughs 
D-825  Modular  Data  Processing  System  is  comparable  to  that  portion  of  the 
CL-II  System  known  as  Primary  CL-II.  Hence  the  AOSP  does  not  purport 
to  be  a  complete  programming  system  which  includes  compilers,  monitors, 
etc.  Instead,  it  should  be  viewed  as  a  general  operating  system,  designed 
for  the  D-825  with  the  aim  of  facilitating  the  use  of  hardware  in  a  multi¬ 
computer  system.  In  fact,  like  Primary  CL-II,  the  AOSP  should  be  viewed 
as  an  extension  of  the  hardware  itself.  Specifically,  the  AOSP  provides 
the  control  for  multi -computer,  multi -processing  in  a  multi-computer 
system  with  shared  high  speed  memory  without  requiring  a  master/slave 
relationship  among  the  computers.  The  AOSP  itself  may  be  executed  by 
more  than  one  computer  simultaneously. 

Although  the  D-825  has  numerous  interesting  system  design  features,  many 
of  which  do  part  of  the  job  of  an  executive  system,  the  most  interesting  pro¬ 
perties  from  a  programming  point  of  view  are: 

(1)  Several  (up  to  4)  independent  computer  modules  may  be  in  opera¬ 
tion  simultaneously,  with  the  entire  memory  accessible  to  each  computer; 

(2)  When  instructions  in  memory  are  being  executed  by  a  computer 
module,  all  addressing  is  relative  to  base  address  registers.  These  regis¬ 
ters  are  in  the  computer  module  (that  is,  not  in  memory). 

The  hardware  permits  any  program  to  be  executed  from  any  location  in 
memory,  referencing  any  other  locations  in  memory,  with  no  change  of  any 
part  of  the  instructions  of  the  program- -only  some  changes  to  the  data  words 
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of  the  program  need  be  made,  and  by  AOSP  convention,  all  of  these  data 
‘  words  are  grouped  into  a  contiguous  block  at  a  standard  (relative)  location 
within  the  program. 

Hence,  there  is  no  need  to  have  more  than  one  copy  of  the  instruction  part 
of  a  program  in  memory,  even  if  two  or  more  entirely  independent  jobs 
call  upon  that  program- -only  separate  copies  of  the  data  part  need  be  made, 
and  the  same  instruction  may  be  executed  simultaneously  by  two  or  more 
separate  computers. 

Insofar  as  the  AOSP  imposes  any  restrictions  on  the  external  or  internal 
forms  of  programs  or  data  sets,  the  restrictions  are  not  onerous,  and  are 
easily  met  by  a  human  programmer  writing  in  assembly  language,  or  by  a 
compiler.  Even  those  operations  which  must  be  performed  by  the  AOSP 
(rather  than  directly  by  the  program)  can  be  specified  in  as  much  detail  as 
the  programmer  chooses.  In  return  for  the  mild  restrictions,  the  program¬ 
mer  is  permitted  greater  freedom. 

No  absolute  addresses  (or  unit  numbers,  etc.  )  are  required.  The  hardware 
is  designed  so  that  there  are  no  preferred  addresses  in  the  machine,  and 
this  feature  is  carried  up  to  the  Extended  Machine.  All  references  to  inde¬ 
pendent  programs  and  external  data  sets  are  by  arbitrary  name.  All  memory 
allocation  is  handled  by  the  system. 

Facility- sharing,  multi-processing,  and  parallel-processing  occur  as  a 
matter  of  course.  As  many  separate  wobs  as  will  fit  in  the  memory  of  the 
machine  may  be  in  process  at  once,  and  as  many  will  be  being  actively  execu¬ 
ted  as  there  are  computer  modules  functioning  in  the  system. 

Indeed,  a  single  job  may  split  itself  into  several  parallel  branches  for  simul¬ 
taneous  execution. 

Response  to  external  signals  for  initiating  new  jobs  is  handled  by  the  system 
without  disturbing  those  already  running;  thus  (except  for  manual  manipula¬ 
tion  of  tape  reels  and  card  decks)  operator  intervention  in  the  system  is 
restricted  to  the  exchange  of  messages  on  the  console  typewriter,  which 
occurs  in  parallel  with  the  running  programs.  The  machine  never  stops, 
short  of  catastrophic  error  conditions. 

Many  of  the  necessary  functions  of  the  system  are  encoded  in  routines 

whose  form  differs  in  no  way  from  a  regular  user's  program,  and  are  therefore 
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subject  to  modification  without  disturbing  the  "Basic  Machine"  portion  of 
the  system. 

The  AOSP  reserves  to  itself  the  execution  of  all  control  mode  machine 
instructions  (halt,  I/O  transmission,  response  to  interrupts,  etc.).  The 
users'  programs,  therefore. have  available  all  of  the  machine's  normal  mode 
instructions,  plus  a  set  of  AOSP  Macros.  These  are  short  instruction 
sequences  which  have  the  effect  of  requesting  the  AOSP  to  perform  some 
function  on  behalf  of  the  calling  program.  These  functions  are  essentially 
ihe  same  as  those  listed  for  Primary  CL-II.  In  addition,  although  they  are 
not  considered  parts  of  the  AOSP  itself,  there  do  exist  file-maintenance 
routines,  assemblers,  compilers,  and  dumps  which  run  under  AOSP  control. 

As  in  Primary  CL-II,  the  AOSP  uses  only  a  simple  job  sequencing  rule. 
Priorities  can  be  assigned  by  an  AOSP  Macro,  and  any  time  one  of  the  com¬ 
puters  in  the  system  is  looking  for  work  to  do,  it  commences  (or  resumes) 
execution  of  the  highest-priority  task  which  is  in  rcady-to-run  status.  When 
it  is  needed,  a  more  sophisticated  monitoring  algorithm  can  be  written. 

The  only  other  important  difference  between  the  AOSP  and  Primary  CL-II 
lies  in  the  area  of  simultaneous  execution  of  parts  of  a  program.  Both 
systems  allow,  as  a  matter  of  course,  the  simultaneous  execution  of  indepen¬ 
dent  programs,  and  both  allow  a  single  program  to  initiate  a  new  parallel 
path  of  control.  However,  within  CL-II,  this  parallel  path  is  a  separate 
named  entity,  possessing  properties  which  can  be  tested  by  functions  of  the 
system.  The  AOSP,  on  the  other  hand,  was  designed  to  be  experimental  in 
this  regard,  and  no  mechanism  for  automatic  coordination  of  parallel  parts 
of  the  same  job  was  provided  in  the  initial  version.  Thus,  the  programmer 
must  explicitly  program  the  synchronization,  and  communication  and  protec¬ 
tion  between  the  parallel  paths  of  his  program  structure.  Basic  facilities 
for  doing  this  are,  of  course,  available  in  the  AOSP. 

The  functions  of  the  AOSP  may  be  considered  in  three  categories: 

(1)  Responding  to  Interrupt  Signals  -  The  AOSP  has  provisions  for 
recognizing  and  dealing  with  all  of  the  numerous  interrupt  conditions  provided 
by  the  hardware;  when  any  such  condition  occurs,  the  computer  module  desig¬ 
nated  to  handle  it  temporarily  suspends  operation  on  its  current  program. 

(2)  Responding  to  Explicit  Requests  from  the  Programmer  -  A  few 
of  these  will  be  specifically  mentioned  below.  An  adequate  set  of  allowable 
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requests  was  included  in  the  first  AOSP,  and  others  have  been  added.  A  very 
important  operation  in  this  category,  for  illustration,  is  the  initiation  of  an 
input-output  operation.  The  completion  of  the  I/O  transmission  is  recognized 
by  a  computer  interrupt,  and  handled  automatically  (Category  1). 

(3)  Monitoring  of  Memory  Organization  and  Program  Control  -  At 
any  instant,  the  system  memory  is  organized  into  numerous  areas,  which 
are  of  different  kinds,  and  have  different  relationships  among  them. 

An  area  of  memory  is  either  available  space,  or  is  (with  certain  systematic 
exceptions)  uniquely  identified  by  its  name  and  file  name.  The  AOSP  has 
at  its  disposal  a  directory  of  the  files  which  currently  exist  in  the  system; 
a  file  is  a  collection  of  objects  (generally  records)  in  an  external  storage 
device  or  in  core  memory.  The  objects  are  programs  or  blocks  of  data; 
an  object  can  be  readied  in  memory  by  simple  request  to  the  AOSP,  giving 
the  object’s  name  and  the  name  of  the  file  on  which  it  resides.  In  addition, 
any  object  may  contain  the  names  and  file  names  of  other  objects  which  are 
necessary  to  it.  These  will  be  readied  automatically  when  the  object  itself 
is  readied.  When  the  object  is  a  program,  this  list  of  necessary  objects  is 
transformed  by  the  AOSP  into  a  block  of  allocation  addresses,  which  the  pro¬ 
gram  may  use  to  reference  the  objects  after  they  have  been  readied. 

Monitoring  of  the  flow  of  control  is  handled  through  a  job  table.  Each  entry 
of  the  job  table  co.  tains  all  the  information  .v-hich  must  be  loaded  into  a  com¬ 
puter  module’s  private  registers  in  order  for  that  computer  to  begin  (or 
resume)  execution  of  a  program;  the  system  is  quite  similar  to  the  state  word 
technique  described  in  "A  Multiprocessing  System  Design,"  M.  E.  Conway, 
Vol.  24,  AFIPS  Conference  Proceedings.  Each  entry  in  the  job  table  repre¬ 
sents  an  independent  path  of  control,  and  there  may  be  an  arbitrary  number 
of  them.  Whenever  a  computer  is  released  from  another  task,  it  proceeds 
to  execute  the  first  available  job  in  the  table.  There  is  a  direct  request 
operation  which  allows  a  program  to  initiate  a  new  job-table  entry,  i.  e.  ,  a 
parallel  path  of  computation  within  the  same  program. 

All  run-time  operator  communication  with  the  AOSP  is  via  the  console  Flexo- 
writer,  which  can  generate  a  peremptory  interrupt.  The  AOSP  constantly 
maintains  in  a  ready  condition  an  instance  of  a  Responder  program  which 
interprets  messages  coming  in  from  the  Flexo  writer.  The  most  frequent  such 
messages  merely  give  the  name  and  file  name  of  a  program  wh;.ch  is  to  be 
executed.  The  Responder  causes  the  entire  structure  of  objects  rooted  at  the 
named  program  to  be  readied  in  memory.  A  job-table  entry  for  this  path  of 


17 


conlrol  is  established  and  program  execution  commences.  There  are  a  few 
special  tasks  the  Responder  can  be  asked  to  pertorm  directly,  (such  as 
terminating  a  particular  job),  and  there  is  an  implicit  system  file  containing 
the  basic  file -handling  programs,  which  can  be  called  without  file  names. 

The  AOSP  is  successful  in  its  primary  purpose  of  making  available  to  the 
programmer  the  facilities  inherent  in  the  hardware.  The  cost  of  this  effec¬ 
tiveness  would  be  extremely  hard  to  define,  let  alone  to  measure.  The 
AOSP  itself  occupies  relatively  few  words  of  memory,  even  with  the  job 
table,  I/O  processing,  etc.  If  necessary  this  could  be  reduced  further  at 
some  cost  in  speed,  by  keeping  parts  of  the  AOSP  on  secondary  storage.  There 
have  been  no  attempts  to  measure  the  percentage  of  time  spent  in  the  AOSP 
during  the  execution  of  programs;  but  since  it  would  be  effectively  impossible 
to  perform  most  of  the  AOSP’s  functions  without  some  sort  of  equivalent 
program,  the  cost  is  hard  to  evaluate. 

The  AOSP  does  require  that  programs  conform  to  certain  conventions  of 
organization.  But  these  restrictions  do  not  appear  unnatural.  It  is  not 
difficult  to  cause  a  compiler  to  produce  code  in  conformity  with  the  required 
structure  and  subjectively,  new  programmers  working  in  symbolic  machine 
language  find  it  harder  to  learn  the  machine  operations  than  to  learn  the 
program  organization.  Also,  a  clever  programmer  finds  it  possible,  if  he 
wishes,  to  violate  the  spirit  of  the  restrictions  without  appearing  to  violate 
the  letter,  if  he  really  needs  to  do  something  for  which  the  AOSP  does  not 
provide. 

The  facilities  for  parallel  processing  were  deliberately  kept  at  a  basic  level. 

It  is  possible  to  initiate  a  new  parallel  path  of  control.  There  are  facilities 
for  awaiting  the  occurrence  of  a  bit  condition,  by  means  of  which  one  path 
can  report  to  another,  and  there  are  facilities  for  temporarily  denying 
access  by  all  other  paths  to  a  particular  block  of  data.  The  intention  was 
to  let  programmers  play  with  these  basic  mechanisms  in  order  to  discover 
what  problems  will  arise,  before  building  in  a  more  complicated  structure 
of  automatic  protection  and  reporting  between  paths.  The  system  is  admit¬ 
tedly  not  designed  for  efficient  parallelism  in  the  small,  e.  g.  ,  for  simul¬ 
taneously  evaluating  two  terms  of  a  sum,  since  it  takes  a  couple  of  milli¬ 
seconds  to  initiate  a  path;  rather,  it  is  designed  for  parallel  operation  of 
relatively  large  segments  of  a  program  structure. 

Some  comments  on  the  machine  configuration  are  useful.  The  AOSP  does 
not  require  an  exact  machine  configuration,  though  it  was  designed  to  operate 
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on  a  general  D825  Data  Processor.  Equipment  availability,  processor, 
memory,  I/O  modules  and  peripheral  devices  are  designated  by  tables. 

In  general,  equipment  may  be  freely  moved  in  or  out  of  the  system.  If  a 
new  type  or  special  purpose  device  is  added  to  the  system,  proper  program 
controls  would  have  to  be  incorporated  into  the  operating  system.  This  was 
realized  in  the  initial  implementation  and  has  been  accomplished  with  rela¬ 
tive  ease  for  various  applications. 

With  respect  to  core  allocation,  there  are  a  number  of  versions  of  the  AOSP 
ranging  from  5000  to  6800  words  of  resident  core.  The  range  depends  on 
the  various  peripheral  devices  on  a  given  system.  However,  in  the  D825,  a 
three  address,  variable  instruction  machine,  the  6800  words  of  core  repre¬ 
sents  approximately  11K  instructions. 

The  initial  implementation  of  AOSP  required  ten  man  years.  Since  then,  an 
additional  ten  to  fifteen  man  years  have  been  spent  on  AOSP.  The  length  of 
time  required  to  design  the  initial  implementation  of  AOSP  was  six  months, 
to  code  it  eight  months  and  for  checkout  four  months. 

C.  INTEGRATED  INFORMATION  PROCESSING  SYSTEM  (INTIPS) 

Project  INTIPS  is  essentially  an  exploratory  development  program  being 
conducted  by  the  Rome  Air  Development  Center,  New  York.  The  objective  of 
the  program  is  the  development  of  a  multi-programming  user-oriented  com¬ 
puter  system.  The  main  element  of  the  INTIPS  system  is  an  executive  routine 
which  is  designed  to  integrate  a  control  computer,  numerous  dissimilar  opera 
tional  cc  ’  outers,  a  hierarchy  of  storage  devices,  a  common  pool  of  peripheral 
equipme;.' *,  and  numerous  consoles  or  query  stations. 

A  program  called  the  Executive  Control  Program  has  been  written  to  coordi¬ 
nate  the  operation  of  the  entire  computer  complex.  Under  this  program's 
control,  it  is  expected  that  any  of  the  computers  may  utilize  any  of  the  peri¬ 
pheral  equipments,  and,  more  importantly,  any  portion  of  the  entire  equip¬ 
ment  complex  can  be  brought  to  participate  in  the  solution  of  the  problems 
of  users  operating  from  their  individual  consoles.  The  Executive  Control 
Program  (ECP  1A)  for  Phase  I  implementation  became  operational  in 
September  1964.  It  is  functionally  modularized  to  facilitate  expansion  and 
revisions  to  accommodate  the  addition  of  new  features  and  characteristics, 
and  to  facilitate  experimentation  with  alternative  approaches.  Among  the 
functionally  independent  modules  in  the  ECP  are  an  input-output  controller, 
priority  and  interrupt  handler,  dynamic  storage  allocator,  program  and 


equipment  scheduler,  and  a  coordinator. 

The  Executive  Control  Program  will  be  executed  from  the  CDC-160A 
Control  computer.  The  language  currently  available  for  use  in  program 
preparation  is  Executive  Control  Program  Interpretive  Language  (ECPIL). 
This  language  is  intentionally  very  similar  to  the  CDC-160A  basic  instruction 
set  and  is  employed  by  the  operational  programmer  in  preparing  programs 
to  be  executed  by  the  Executive  Control  Program.  More  sophisticated 
languages  are  being  anticipated  for  later  INTTPS  implementation. 

In  its  current  state  of  development  the  Executive  Control  Program  is  expected 
to  handle  up  to  five  independent  programs  at  any  one  time  on  any  given  com¬ 
puter  in  the  complex.  Additional  jobs  will  be  stored  in  a  job  queue. 

Part  of  the  equipment  configuration  for  INTIPS  includes  an  Interim  Exchange 
(DC-400).  This  will  be  replaced  by  a  Central  Exchange  (CX-400)  in  a  later 
version. 

The  Interim  Exchange  is  a  3-by-15  electronic  switch  capable  of  accommo¬ 
dating  up  to  three  computing  or  "controlling"  modules  and  up  to  15  non¬ 
computing  or  "controlled"  modules.  Any  of  the  "controlling"  modules  can 
request  a  connection  to  any  of  the  "controlled"  modules  with  a  special 
instruction  recognized  and  executed  by  the  Executive  Control  Program. 

The  Central  Exchange  which  will  replace  the  Interim  Exchange  is  a  l6-by-6l 
electronic  switch  capable  of  accommodating  up  to  16  "controlling"  modules 
and  up  to  61  "controlled"  modules.  It  contains  its  own  internal  memory 
(1024  words)  and  can  execute  seven  special  instructions,  five  of  which  are 
given  directly  to  the  Central  Exchange  and  may  be  given  by  any  controlling 
module;  the  remaining  two  instructions  are  given  to  the  Master  Coordinate 
of  the  CX  and  may  be  given  only  by  the  Control  Computer. 

The  Control  Computer  makes  the  assignments  of  controlled  modules  to  the 
controlling  modules  via  the  Symbolic  File. 

The  Symbolic  File  resides  in  the  1024  word  memory  of  the  Central  Exchange 
and  allows  the  Control  Computer  to  store  assignments  for  symbolic  addres¬ 
sing  of  controlled  modules  and  of  alerts  and  to  store  a  history  of  the  last 
request  and  action  taken  at  each  controlling  module. 
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With  respect  to  storage  allocation,  one  of  the  major  characteristics  of  the 
system  is  that  all  information,  data  as  well  as  programs,  is  stored  in  seg¬ 
ments/overlays  of  512  words.  A  program  may  occupy  from  one  to  seven 
contiguous  segments  of  (core)  memory.  Programs  may  be  of  infinite 
length,  but  no  more  than  the  number  of  segments/overlays  specified  in  the 
Job  Control  Record  (JCR)  will  reside  in  memory  at  any  given  time.  The 
term'  "Segment"  refers  to  a  512-word  block  of  information  contained  in  the 
control  computer  memory,  whereas  the  term  "overlay"  refers  to  a  512- 
word  information  block  in  auxiliary  storage.  That  is  to  say,  segments  are 
numbered  from  one  through  seven  with  reference  to  their  physical  positions 
in  memory  whereas  overlays  in  auxiliary  storage  are  numbered  according  to 
their  position  in  a  program  or  data  file.  All  input/output  transfers,  with  the 
exception  of  "Print"  and  "Display"  are  of  an  entire  512-word  segment/overlay. 
When  ECP  1A  loads  a  job  program  for  execution,  it  places  only  the  first  over¬ 
lay  into  memory.  Each  successive  overlay  must  then  call  in  others  as 
required  through  appropriate  instructions  which  have  been  provided  automati¬ 
cally  by  an  assembly  program.  All  addresses  are  assigned  relative  to 
"zero"  in  operational  and  all  overlays,  data  or  program,  are  completely 
relocatable  under  ECP  1A  control. 


The  major  contribution  of  the  initial  INTIPS,  when  completed,  will  be  in  the 
area  of  executive  control.  The  nature  of  that  contribution  will  be  in  eluci¬ 
dating  the  kinds  of  techniques  required  of  an  executive  routine  whose  major 
function  is  the  efficient  integration  of  an  heterogeneous  configuration  of 
hardware. 

D.  DEPARTMENT  OF  DEFENSE  DAMAGE  ASSESSMENT  CENTER  (DODDAC) 


The  current  Department  of  Defense  Damage  Assessment  Center  (DODDAC) 
activity  includes  data  reduction,  data  base  creation,  and  a  number  of  compli¬ 
cated  damage  assessment  models,  including  Rapid  Damage  Assessment  and 
Hazard  and  Vulnerability  models.  System  Development  Corp.  ,  Santa 
Monica,  Calif.  ,  has  developed  a  software  system  for  controlling  these  tasks 
known  as  the  Executive  Control  System  for  a  CDC  1604-160  computer  complex 
which  includes  tapes,  discs,  and  CRT  displays.  The  Executive  Control 
System  provides  the  linkage  between  the  various  system  elements--programs, 
hardware,  and  operators.  It  is  the  internal  mechanism  through  which  users 
and  operators  exert  control  and  interact  with  the  DODDAC  program  system. 

The  Executive  Control  System  performs  the  following  specific  functions: 
system  start-up;  mode/model  control;  equipment  monitoring;  interrupt 
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processing;  operator-program  communication;  control  of  input/output  data 
flow;  1604-satellite  intercommunication;  initial  request  interpretation; 
priority  and  queuing;  task  control;  and  program  and  environment  sequence 
control. 

The  system  is  comprised  of  four  distinct  programs: 

(1)  Executive  Control  Program  (ECS) 

(2)  Executive  Start-Up  Program  (ESU) 

(3)  Mode/Model  Control  Program  (ECC) 

(4)  Non-operational  Request  Processing  Program  (ECN) 

ECS,  which  refers  to  a  specific  program,  not  the  entire  Executive  Control 
System,  consists  of  several  components  comprising  the  permanent  core 
portion  of  the  Executive  Control  System.  The  individual  components  of 
ECS  perform  the  functions  of  master  control,  interrupt  processing,  on-line 
card  processing,  request  interpretation,  priority  and  queuing,  task  control, 
program  and  environment  control,  data  collection  and  input/output.  The 
last  function  is  performed  by  the  Input/Output  Monitor,  a  group  of  sub¬ 
routines  assembled  as  part  of  ECS  . 

ECS  directly  controls  the  operation  of  the  other  Executive  programs  and 
the  operational  models,  Rapid  Damage  Assessment  (RDA)  and  Hazard  and 
Vulnerability  (H  &  V).  It  controls  the  sequencing  of  programs  and  environ¬ 
ment  for  RDA  and  H  It  V  by  interpreting  tables  of  preset  sequence  parameters 
The  non-operational  subsystems,  Utility,  Data  Base  Load,  and  Data  Reduc¬ 
tion,  have  separate  control  programs  which  guide  internal  program  and 
environment  sequencing;  however,  they  initially  obtain  control  from  the 
Executive  Control  System.  Because  the  non-operational  subsystems  destroy 
the  permanent  core  Executive,  they  return  control  to  ECS  by  reading  in  and 
branching  to  the  Start-up  Program  (ESU). 

The  non-permanent  core  Executive  programs,  ESU,  ECC,  and  ECN,  exist 
in  core  only  when  their  specific  services  are  needed.  ESU,  which  is  read  in 
by  a  paper  tape  bootstrap,  prepares  for  the  operation  of  the  DODDAC  system 
by  communicating  with  the  computer  operator  to  obtain  time  and  equipment 
information  and  by  establishing  the  initial  system  environment.  ESU  com¬ 
pletes  its  responsibilities  by  reading  in  and  transferring  control  to  ECS. 
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ECS  reads  in  and  transfers  control  to  ECN  when  it  is  necessary  to  interpret 
or  process  a  non-operational  request.  If  possible,  ECN  implements  the 
request  itself  and  returns  control  to  ECS.  More  frequently,  ECN  reads*  in 
and  transfers  control  to  a  non-operational  program  or  subsystem  which 
performs  the  required  functions  and  returns  control  to  ECS.  Because  of  the 
extensive  capability  of  the  ECS  to  p.ovide  linkages  between  very  large  and 
very  Complicated  system  and  user  programs,  as  well  as  between  system 
users  and  system  hardware,  the  ECS  qualifies  as  an  example  of  the  general 
purpose  programming  approach  to  computer  system  design.  This  is  not  to 
say,  however,  that  DODDAC  is  completely  characterized  by  its  ECS.  Rather 
the  system  includes  an  extensive  set  of  data  management  functions  as  well. 
Among  these  functions  are:  the  Data  Base  Load  Subsystem,  miscellaneous 
support  programs,  and  the  OASIS  subsystem.  A  description  of  this  latter 
subsystem  follows. 

E.  OASIS  SUPPORT  SYSTEM  FOR  DODDAC 

The  OASIS  support  system  was  built  to  provide  an  environment  for  the  devel¬ 
opment,  check-out,  and  operation  of  DODDAC  operational  programs.  OASIS 
was  superimposed  on  the  conventional  CDC  software;  this  software  being, 
at  times,  degraded  in  the  process. 

OASIS  includes  a  JOVIAL  compiler  and  an  assembly  program  which  can  oper¬ 
ate  from  a  COMPOOL  of  data.  The  system  controlled  the  operation  of  pro¬ 
grams  which  had  been  previously  stored  on  a  Master  Tape.  All  space  alloca¬ 
tion  problems  are  handled  by  the  programmer  explicitly.  Only  absolute  binary 
programs  are  stored  on  the  Master  Tape.  In  order  to  operate  the  system, 
the  programmer  must  communicate  control  information  to  the  system  via  the 
card  reader  for  every  phase  of  the  processing.  For  example,  four  phases 
are  required  to  compile  and  add  a  JOVIAL  program  to  the  OASIS  Marker 
Tape.  A  sample  control  card  deck  to  perform  this  follows: 

CLEAR:  Command  to  a  utility  program  to  clear  core. 

LOAD:  Command  to  perform  a  card-to-tape  operation  on  the 

JOVIAL  source  deck,  moving  it  from  the  card  reader 
to  a  specified  tape. 

JOVIAL:  Command  to  perform  the  compilation,  the  ou'put  of 

which  is  standard  input  to  the  CDC  assembler,  CODAP. 
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WAIT:  Command  to  the  operator  to  switch  tapes;  system 

awaits  completion. 

UPP:  Command  to  invoke  a  "preprocessor"  which  modifies 

the  standard  CODAP  input  for  COMPOOL  data 
elements. 


UAA:  Command  to  perform  an  assembly  (with  a  modified 

CODAP  routine)  the  output  of  which  is  an  absolute 
binary  routine. 

UMT:  Command  to  a  utility  routine  to  add  the  binary  routine 

to  a  Master  Tape. 

Separate  programs  are  combined  into  larger  operating  units  via  a  system 
routine  that  requires  that  the  components  be  listed  and  the  order  of  execu¬ 
tion  specified.  The  programmer  supplies  the  system  with  the  disc  address 
or  tape  record  address  of  each  component.  All  programs  have  been  pre¬ 
viously  bound  to  absolute  memory  locations  and  the  programmer  is  respon¬ 
sible  for  memory  allocation. 


F.  NECPA  MASTER  CONTROL  SYSTEM 


The  NECPA  (National  Emergency  Command  Post  Afloat)  Master  Control 
System  (MCS)  is  an  executive  system  which  performs  the  following  processes: 

(1)  Controls  and  schedules  NECPA  Data  Processing  System  to  work 
on  tasks  of  highest  user-defined  priority. 

The  MCS  has  a  table  of  tasks  m  waiting  ordered  by  priority. 

This  table  has  an  associative  list  structure.  The  MCS  has  the 
capability  of  changing  priority  of  any  task  in  the  waiting  task 
table  and  can  also  be  called  upon  to  cancel  or  delete  any  entry 
in  this  table.  The  MCS  has  the  ability  to  print  out  upon  request, 
any  or  all  of  its  tables. 

(2)  Controls  I/O  operations  to  allow  a  set  of  'psuedo -offline' 
operations  to  process  independently  of,  but  concurrent  with,  the 
program  being  executed. 
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The  MCS  controls  all  the  I/O  for  the  system  in  an  attempt  to 
optimize  I/O  throughput  by: 

(a)  Maintenance  and  interrogation  of  an  I/O  configuration 
matrix. 

(b)  Control  of  assignment  of  physical  tape  channels  and  units. 

(c)  Implementation  of  tasks  by  parallel  rather  than  sequential 
I/O  data  transfer. 

(3)  Maximizes  system  throughput. 

The  MCS  allocates  channels  and  units  to  give  the  optimum  overlap 
for  parallel  reading  and  writing  of  data. 

(4)  Reallocates  vital  system  functions  in  the  event  of  certain  types 
of  system  equipment  degradation. 

In  the  event  of  degradation  of  the  system  I/O  configuration,  the 
MCS  reallocates  I/O  equipment  to  perform  the  essential  tasks 
and  also  attempts  to  optimize  the  I/O  within  the  degrading  con¬ 
figuration.  The  MCS  can  interrupt  any  task  currently  being 
processed  and  save  the  results  for  restoration  at  a  later  time. 

(5)  Maintains  list  of  jobs  in  job  queue. 

(6)  Maintains  tape  log.  The  MCS  maintains  a  log  of  all  data  tapes 
required  by  functional  programs.  Some  of  the  information  con¬ 
tained  in  this  log  are  (a)  identification  of  each  file,  or  (b)  date  of 
last  update,  (c)  number  of  physical  reels  comprising  a  file, 

and  (d)  the  security  classification  of  each  file. 

(7)  Checks  security  classification  of  job  and  tapes  required  for  jobs. 

(8)  Informs  operator  of  all  significant  system  events.  The  MCS 
keeps  a  set  of  system  statistics.  Some  of  the  functions  carried 
out  by  this  set  of  programs  are: 

(a)  Informs  and  instructs  operator  about  all  input  data  error  < 
or  ambiguities. 
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(b)  Informs  operator  whenever  task  is  begun,  completed, 
interrupted,  resumed,  or  cancelled. 

(c)  Upon  completion  of  task  MCS  reports: 

Description  of  task 
Number  of  interruptions 
Completed  tapes  saved 

(d)  Upon  completion  of  system  shift  MCS  reports: 

Completed  tasks 
Cancelled  tasks 
Deleted  tasks 

Uncompleted  tasks  with  restart  information 

(9)  Checks  and  positions  all  tapes  mounted  for  jobs.  The  MCS 
checks  that  the  most  recent  version  of  a  file  is  being  used 
unless  specifically  overridden  by  the  task  request  or  by  the 
operator. 
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PART  II.  FUNCTIONAL  SYSTEMS 


In  this  section  those  systems  which  have  been  designed  to  perform  a  large 
and  complicated,  but  nonetheless  well  delineated  job  function,  are  discussed. 
(The  systems  which  follow  exemplify  the  job  function  of  information 
retrieval.  There  are,  of  course,  quite  different  systems,  such  as  Lincoln 
Laboratory  s  GENDARE  which  is  designed  specifically  for  data  reduction,  but 
they  have  been  omitted  to  simplify  the  discussion.  )  The  necessity  for  pro¬ 
viding  the  user  with  a  functional  capability  has  overridden  the  desire  to  provide 
powerful  programming  capability.  Thus  the  systems  listed  here  have  been 
designed  to  perform  a  specific  function  and  the  ultimate  design  criterion  was 
not  one  of  system  generalization,  programming  sophistication,  system  evolu¬ 
tion  or  man-machine  flexibility.  Rather  the  ultimate  criterion  for  design 
decisions  was  whether  or  not  a  particular  alternative  would  contribute  to 
the  performance  of  the  system  in  that  function  which  it  would  exercise  more 
than  any  other.  This  is  not  to  say  that  the  systems  which  follow  are  lacking 
in  flexibility,  evolutionary  growth,  or  generalization.  In  fact,  many  of 
them  show  striking  advances  in  each  of  these  properties.  Rather,  what  is 
characteristic  of  the  approach  embodied  in  these  systems  is  that  whenever 
an  either/or  decision  had  to  be  made  with  respect  to  improving  the  informa¬ 
tion  retrieval  capability,  i.  e.  ,  the  functional  capability  of  a  given  system  at 
the  expense  of  evolution,  generalization,  flexibility,  etc.  ,  the  decision  was 
always  made  to  enhance  the  function  at  the  expense  of  the  general  capability. 

A.  COMPILE  ON-LINE  AND  GO  (COLINGO) 

COLINGO  (Compile  On-LINe  and  GO)  is  a  general  purpose  storage  and 
retrieval  system  developed  for  the  USSTRICOM  Interim  Command  and  Con¬ 
trol  System  by  the  MITRE  Corporation,  Bedford,  Massachusetts. 

COLINGO  provides  a  set  of  modular  computer  programs  for  file  generation, 
file  maintenance,  data  retrieval,  and  control  on  an  IBM  1401  computer. 

Mathematical  and  logical  operations  using  the  system's  data  base  are 
provided  by  both  stored  program  and  on-line  programming  techniques 
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through  the  use  of  the  COLINGO  Control  Language.  Control  of  the  data, 
computer  programs,  and  equipment  is  achieved  through  on-line  interpre¬ 
tive  execution  of  statements  in  this  language  entered  by  cards  or  from  a 
single  console  typewriter.  The  design  includes  a  Basic  Program  Set  which 
provides  programs  for  rapid  and  convenient  data  file  update,  data  file  addi¬ 
tion,  and  stored  program  addition.  Programs  are  constructed  as  closed  sub¬ 
routines  which  may  be  written  in  Autocoder,  SPS  or  COBOL.  This  design 
allows  expansion  of  the  Basic  Program  Set  '’’d  the  addition  of  special 
purpose  and  convenience  features.  On-lin«  generation  and  on-line  pro¬ 
gramming  in  COLINGO  are  an  integral  part  o',  the  system  design.  Special 
data  maintenance  and  verification  routines,  as  well  as  automated  system 
dictionary  and  vocabulary  preparations,  are  also  included  in  the  system. 
These  features  will  permit  evolutionary  growth  of  the  system  and  provide  the 
capability  to  produce  special  purpose  operational  programs  with  a  minimum 
of  programming  time. 

The  data  acceptable  to  the  COLINGO  system  can  vary  widely  in  type,  but  will, 
in  general,  be  structured  in  files  according  to  a  uniform  set  of  rules.  Con¬ 
sequently,  the  procedures  and  programs  used  to  retrieve  and  process  the 
data  can  be  made  applicable  to  any  data  by  designing  the  programs  to  process 
formats  and  not  the  data.  Moreover,  new  files  can  be  introduced  into  the 
system  and  files  in  the  computer  can  be  changed  or  deleted  with  no  change 
to  the  retrieval  programs. 

Data  files  consist  of  serial  records  with  provisions  for  unlimited  trailer 
records.  Any  number,  or  order,  or  size  of  unique  fixed-field  data 
categories  is  permitted.  Files  are  organized  to  three  levels:  file,  Droperty 
and  sub-property;  and  are  described  by  the  COBOL  data  division  format. 

The  COBOL  data  division  is  preprocessed  by  a  dictionary  and  ind^x  genera¬ 
tion  program  to  organize  the  data  description  into  a  fixed-format  dictionary 
for  use  by  the  COLINGO  program.  All  properties  and  subproperties  may 
be  retrieved. 

In  addition  to  the  tape  files  COLINGO  has  26  QUIC  files  on  disk.  These  files 
are  packed  and  can  be  generated  in  a  very  flexible  manner.  Retrieval  from 
the  QUIC  files  is  much  faster  than  retrieval  from  the  tape  files.  Normally 
several  of  these  files  are  used  for  stored  queries,  lists  of  files  in  the 
system,  report  masks,  etc. 

Dictionaries  and  vocabularies  are  maintained  for  the  entire  data  base. 

File  generation,  updating,  regeneration  and  deletion  all  cause  automatic 
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updating  of  the  dictionary  indices  and  vocabularies.  Files  generated  out¬ 
side  of  the  COLINGO  system  require  preprocessing. 


The  basic  retrieval  function  in  COLINGO  is  specified  by  the  Query  State¬ 
ment  which  consists  of  three  parts:  the  File  Statement  (which  names  the 
file  to  be  interrogated);  the  Criteria  Statement  (which  specifies  the  selection 
criteria);  and  the  Output  Statement  (which  describes  the  desired  output  infor¬ 
mation,  the  output  device(s),  and  any  desired  manipulation  of  the  retrieval 
data). 

Example  of  Query  Statement: 

(File  Statement)  GET  AIRFIELD -FILE 

(Criteria  Statement)  IF  RUNWAY/LENGTH  EQ  5000 

(Output  Statement)  PRINT  RADAR/ TYPE 

The  parenthesized  words  in  the  example  are  for  illustration  and  do  no* 
appear  in  the  Query  Statement.  The  above  example  would  print  out  the  type 
of  radar  found  at  each  airfield  in  the  AIRFIELD  file  that  had  a  runway  5000 
feet  in  length. 

Apart  from  the  basic  Query  Statement,  the  Control  Language  has  certain 
special  features  some  of  which  are  mentioned  below: 

.  Misspellings  may  be  corrected  by  the  operator  at  the  type¬ 
writer  before  the  statement  is  entered. 

.  Column  headings,  titles,  security  classifications,  date  and 

time,  page  number,  etc.  ,  may  be  specified  (some  come  automa¬ 
tically)  . 

Query  input  and  hard  copy  output  can  be  assigned  by  the  operator 
to  a  variety  of  devices. 

The  operator  can  interrupt  any  query  and  suspend  or  discontinue 
it. 

Provision  is  made  to  store  any  query  statement  which  may  then 
be  invoked  by  name. 


Comments  to  the  operator  may  be  imbedded  in  stored  queries. 

.  On-line  changing  and/or  sorting  on  selected  properties  is 
permitted. 

.  Arithmetic  expressions  involving  constants  and  retrieval  data 

fields  may  be  specified  by  the  user  and  interpretively  evaluated. 

Direct  provisions  are  made  in  the  Control  Language  for 
dictionary  and  file  addition,  insertion,  replacement  and  removal. 

.  Queries  may  call  one  or  more  other  queries. 

.  ThelF/NOT  function  permits  conditional  branching  wihin  a  query 
run  (ex.  IF  RUNWAY/LENGTH  LQ  5000  EXECUTE  SHORT  IF/ 
NOT  EXECUTE  LONG  where  SHORT  and  LONG  are  other 
queries. ) 

.  Variables  may  be  inserted  in  previously  stored  queries  on-line. 

,  The  COMPUTE  verb  will  cause  the  evaluation  of  FORTRAN-like 
arithmetic  expressions. 

.  Qualifying  records  may  be  counted  and  property  or  sub-property 
values  may  be  summed. 

.  Data  output  may  be  by  one  of  the  standard  output  formats 
provided  or  through  a  report  mask  specified  by  the  user. 

Several  error  messages  appear  automatically.  They  essentially  say  "A 
parameter  is  missing,  "  "What  you  want  does  not  exist"  or  "I  don*t  under¬ 
stand  you.  " 

The  principal  subroutines  of  the  COLINGO  system  include:  a  disk  handling 
routine  with  bootstrap;  tape  handler  with  bootstrap;  four  dictionaries  with 
their  own  search  routines;  a  dictionary  updater;  a  disc  allocator;  various 
output  routines  and  routines  for  decoding  and  executing  query  statements. 

The  essential  characteristic  of  COLINGO  is  its  ability  to  map  any  data  base 
format  into  its  own  format  in  a  very  short  time  and  then  to  query  the  resultant 
formatted  data  with  facility.  As  a  consequence,  COLINGO  is  a  highly  flexible 
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information  retrieval  system.  It  is  this  characteristic,  rather  than  the 
nature  of  its  query  language  or  the  structure  of  its  executive  routine,  that 
was  of  primary  importance  to  the  system  designers.  However,  the  ability 
to  chain  queries  and  store  them  for  subsequent  use  permits  complex 
procedures  involving  extracted  data  to  be  constructed  on-line.  Thus, 
COLINGO  also  has  some  desirable  features  of  a  user-on-line  system.  On 
the  other  hand,  COLINGO  has  certain  shortcomings  which,  from  the  point 
of  view  of  efficiency,  make  it  undesirable  as  a  universal  tool  in  other  areas 
where  flexibility  in  data  retrieval  may  be  considered  unnecessary. 

B.  NAVCOSSACT  INFORMATION  PROCESSING  SYSTEMS 

The  NAVCOSSACT  Information  Processing  Systems  have  evolved  through  a 
developmental  process.  The  first  system  was  developed  for  the  David 
Taylor  Model  Basin  in  1961.  This  system,  for  the  IBM  704,  was  further 
developed  into  the  current  system  operating  on  the  CDC  1604  at  CINCPAC, 
the  Univac  USQ-20  for  the  National  Emergency  Command  Post  Afloat,  and 
the  7090  at  the  Navy  Information  Center  in  the  Pentagon.  All  of  the  current 
systems  are  essentially  similar;  differences  stem  mainly  from  the  unique 
characteristics  of  the  hardware  they  utilize.  The  following  writeup 
describes  the  principal  features  of  the  NAVCOSSACT  Information  Proces¬ 
sing  System  in  terms  of  the  CINCPAC  System. 

The  NAVCOSSACT  Information  Processing  System  is  a  set  of  programs 
which  generates  and  maintains  formatted  files  of  information  and  selectively 
retrieves  data  from  the  files.  These  programs  are: 

(1)  File  Maintenance  Subsystem,  which  generates  and  updates 
formatted  files  on  magnetic  tapes. 

(2)  The  Information  Retrieval  Subsystem,  which  retrieves  infor¬ 
mation  from  magnetic  tapes  and  formats  printouts  in  a  use¬ 
ful  manner. 

(3)  Library  Maintenance  Subsystem,  which  generates  and  updates 
the  information  processing  system  library.  The  library  is  a 
magnetic  tape  file  of  several  types  of  tables  used  by  the  file 
maintenance  and  retrieval  programs. 

The  system  is  said  to  be  generalized  because  it  will  process  any  members 
of  a  group  of  files  having  a  specified  structure.  Generality  is  achieved 
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through  the  format  table.  Every  master  file  has  a  format  table  which 
identifies  the  items  or  data  fields  in  every  record  in  the  file  and  describes 
the  characteristics  of  the  items.  The  user  of  the  information  processing 
system  describes  the  operations  to  be  performed  on  a  file  in  a  language 
which  resembles  a  procedure-oriented  programming  language.  Routines 
in  the  information  processing  system  programs  use  the  data  descriptions 
in  the  format  table  to  translate  statements  in  the  language  into  tables 
which  direct  the  programs  in  performing  specific  operations. 

The  File  Maintenance  System  generates  and  maintains  the  data  files. 

The  user  defines  the  format  of  each  file  through  the  use  of  a  file 
format  table  and  then  manipulates  the  data  through  the  use  of  the  provided 
Macro  Instructions. 

The  File  Maintenance  System  allows  the  user  to  define  Argument- Function 
Value  or  Code  Conversion  tables.  These  tables  are  used  to  convert  coded 
information  to  uncoded  form  and  vice-versa.  They  are  referenced  by  the 
table  LOOK  UP  Macro  Instruction. 

The  Macro  Instructions  are  divided  into  four  basic  categories:  (1)  environ¬ 
ment  establishing  instructions  to  step  through  the  file,  (2)  data  handling 
instructions,  (3)  control  instructions  for  branching,  and  (4)  output  instruc¬ 
tions.  They  are  composed  of  a  Tag  Field,  an  Operation  Field,  and  a 
Variable  Field.  Examples  of  data  handling  and  environment  establishing 
instructions  are: 

TAG  MOVE  B  TO  A  $ 

STEP  AIRFIELD  RETURN  TO  TAG  $, 

where  TAG  is  a  label,  AIRFIELD  is  a  file,  and  A  and  B  are  variables. 

Macro  instructions  may  move  information  from  a  transaction  record  to  a 
master  record.  Data  conversion  and  generation  of  new  data  may  be  per¬ 
formed.  Source  data  may  be  checked  for  validity,  and  messages  may  be 
written  on  a  print  tape  to  identify  errors  which  occur  during  processing. 

A  transaction  file  may  consist  of  source  data  on  punched  cards,  punched 
paper  tape,  etc.  ,  or  it  may  be  a  master  file.  A  source  data  transaction  file 
is  a  formatted  file,  although  it  does  not  conform  to  the  specifications  for 
master  files.  It  may,  in  fact,  have  records  in  two  or  more  different  formats. 
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in  which  case  each  record  will  have  a  field  identifying  the  format  of  the 
record.  Associated  with  each  different  transaction  record  format  is  a 
set  of  macro  instructions  which  specifies  the  operations  to  be  performed 
on  records  having  the  designated  format. 


When  a  master  file  is  generated,  records  are  read  sequentially  from  the 
transaction  file,  with  the  designated  set  of  macro  instructions  being 
"executed"  each  time  a  record  is  read.  When  the  file  maintenance  pro¬ 
gram  determines  that  all  transaction  records  having  the  same  keyfield  have 
been  read,  a  record  is  written  on  the  new  master  file.  In  the  special  case 
of  each  transaction  record  having  a  unique  keyfield,  a  master  record  will 
be  written  for  each  transaction  record  that  is  read. 


When  a  master  file  is  updated,  records  are  read  sequentially  from  both  the 
transaction  and  master  files.  When  a  match  occurs  between  transaction 
and  master  keyfields,  a  set  of  macro  instructions  is  executed,  causing  a 
master  record  to  be  updated.  If  the  purpose  of  a  transaction  record  is  to 
generate  a  new  master  record,  the  file  maintenance  program  will  recognize 
that  no  corresponding  record  exists  on  the  master  file  being  read  and  will 
execute  the  macro  instructions  at  the  proper  time. 


The  information  retrieval  program  has  a  COLINGO -like  query  language 
with  approximately  the  same  retrieval  capabilities.  It  accepts  as  input 
a  master  file  and  a  set  of  one  or  more  queries  requesting  information  from 
the  file.  Queries  are  written  in  information  retrieval  language,  in  free 
form,  on  punched  cards.  There  is  no  provision  for  on-line  typewriter 
input.  A  query  has  two  major  parts:  an  "output  statement"  which  designates 
the  items  requested  as  output  and  the  format  of  the  output,  and  a  "search 
statement"  which  specifies  the  conditions  which  items  in  a  record  must 
meet  for  information  to  be  retrieved  from  the  record.  The  output  of  the 
program  is  written  on  one  or  more  tapes  for  printing. 

J 

The  program  is  modular  and  operates  in  either  three  or  four  phases, 
depending  upon  the  type  of  output  desired.  The  first  phase  translates  a 
set  of  queries  from  information  retrieval  language  to  tables  which  control 
the  operation  of  succeeding  phases.  The  second  phase  searches  the 
master  file  for  records  which  meet  the  conditions  specified  in  the  search 
statements  of  queries.  When  a  record  is  found  which  satisfies  the  condi¬ 
tions  stated,  all  or  part  of  the  record  is  written  on  one  of  two  scratch  tapes, 
depending  upon  the  type  of  output  desired.  Some  queries  do  not  require  a 
search  statement;  they  will  cause  data  to  be  taken  from  every  record  of  the 
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master  file  and  written  on  a  scratch  tape. 

The  third  phase  is  a  magnetic  tape  sort  routine.  Certain  types  of  output 
require  that  the  data  be  sorted  on  one  or  more  items.  The  records  to  be 
sorted  are  on  one  of  the  two  scratch  tapes  generated  in  phase  two.  The 
fourth  phase  reads  the  scratch  tapes,  edits  the  data,  and  writes  the  out¬ 
put  tapes  for  printing. 

There  are  several  minor  differences  between  the  Information  Retrieval 
System  (IRS)  and  COLINGO  query  languages  such  as: 

.  IRS  may  use  a  function  which  requires  computation  as  criteria 
to  qualify  a  record.  COLINGO  would  require  one  pass  of  the 
file  to  compute  the  function  and  another  pass  for  qualification. 

.  A  pattern  compare  capability  (IF  MORALE  EQ  EXCELLENT 
would  qualify  in  IRS  if  the  variable  item  contains  the  value 
THE  MORALE  OF  COMPANY  B  IS  EXCELLENT.) 

.  The  IRS  SUM  verb  may  have  several  operands;  COLINGO 
allows  only  one. 

.  IRS  requires  parentheses  around  operands,  if  they  are  values. 

.  IRS  has  a  more  powerful  COUNT  verb  which  will  give  subtotals 
for  the  count  of  each  property  value  and  a  total  count  for  the 
property.  COLINGO  will  only  give  the  total  count  of  the  number 
of  records  that  qualify. 

.  The  IRS  SORT  routine  gives  an  ascending  sort.  COLINGO  has 
both  ascending  and  descending  sorts. 

.  IRS  does  not  have  the  capability  for  conditional  branching  while 
executing  a  string  of  stored  queries. 

.  IRS  has  approximately  the  same  output  capability  that  COLINGO 
has  and  both  allow  the  user  to  add  his  own  special  output  routine. 

The  Library  Maintenance  System  provides  the  means  for  the  generation  and 
maintenance  cf  the  Library  File,  which  corresponds  to  COLINGO’s  QUIC 
files.  The  files  contain  a  master  dictionary,  stored  queries,  format  tables 
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macro-instruction  lists,  and  code  conversion  tables.  Updating  a  Library 
File  consists  of  adding,  deleting,  or  replacing  an  entire  file  or  table. 

NAVCOSSACT  Information  Processing  System  has  a  considerably  greater 
number  of  error  messages  than  COLINGO  has;  however,  due  to  the  restric¬ 
tions  on  the  format  of  the  card  input,  it  is  also  easier  for  an  error  to  be 
made. 

The  hardware  environment,  in  existence  in  the  facilities  for  which  NAVCOS¬ 
SACT  has  been  responsible  and  IBM  has  provided  the  programming  systems, 
is  quite  dissimilar.  The  hardware  at  the  various  centers  include  the 
IBM  7090,  the  AN/FYK-1(Y)  Data  Processing  Set  produced  by  CDC,  and 
the  AN/USQ-20  produced  by  Sperry  Rand  Corporation. 

Outlined  below  are  hardware  configurations  and  the  IP  systems  that  have 
been  designed  for  each  .  (These  do  not  represent  minimum  configurations 
on  which  the  systems  will  operate.) 

NAVIC  Information  Processing  System 

IBM  7090 

Hardware  configuration: 

1  IBM  7090  computer  with  32K  word  memory 
11  IBM  729  VI  tape  drives 

4  IBM  729  V  tape  drives  switchable  with  the  IBM  1401 
computer 

2  IBM  1301  (4  modules)  disk  units 

Capacity  is  about  108,000,  000  characters 

CINCPAC  Infoi-mation  Processing  System 
AN/FYK-1(Y)  Data  Processing  Set 

The  AN/FYK-1(Y)  Data  Processing  Set  is  an  integrated  system  consis¬ 
ting  of  1604A  and  160A  CDC  computers  with  switchable  peripheral 
equipment.  The  AN/FYK-1(Y)  is  implemented  at  CINCPAC. 
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Hardware  configuration: 

4  CDC  1604A  computers  with  32K  word  memory 
IBM  1402  card  reader/punch 
(up  to)  28  IBM  729  IV  tape  drives 
1  Analex  printer 

1  CDC  160A  for  the  Master  Control 
4  CDC  160A  computers 

Remington  Rand  USQ-20 

An  information  processing  system  has  been  developed  for  the  USQ-20 
computer  in  support  of  NECPA. 

Hardware  configuration: 

1  USQ-20  with  32K  word  memory 
12  RD  1241  tape  drives 

1  Paper  tape  reader/punch 

2  Analex  printers 

1  AN/UGC-13  teletype 

2  Card  readers 
2  Card  punches 


C.  TUFF- TUG 

The  systems  known  as  TUFF  (Tape  Update  of  Formatted  Files)  and  TUG 
(Format  Table  Tape  Updater  and  Generator)  were  earlier  generation 
programs  for  the  704/7090  which  were  functionally  equivalent  to  the 
NAVCOSSACT  File  Maintenance  and  Library  Maintenance  Systems  dis¬ 
cussed  above. 

D.  1410  FORMATTED  FILE  SYSTEM  (FICEUR) 

The  IBM  1410  Formatted  File  System  (FFS)  is  a  generalized  system  of 
programs  designed  to  build,  maintain,  retrieve  from,  and  produce  reports 
on  a  wide  variety  of  information  files.  The  system  is  in  operation  at  a 
number  of  Air  Fcrce  Commands  as  part  of  the  Intelligence  Data  Handling 
System  (IDHS)  centers  as  well  as  in  the  Fleet  Intelligence  Center  Europe 
(FICEUR). 
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Files  in  the  Formatted  File  System  look  much  the  same  as  COLINGO 
files.  Both  systems  allow  for  three  levels  of  organization,  and  both  sys¬ 
tems  maintain  a  dictionary  or  file  format  table  describing  the  file  struc¬ 
ture.  The  one  significant  difference  in  file  structure  is  the  Formatted 
File  System’s  provision  for  variable  length  fields. 

In  the  Formatted  File  System  the  user  may,  by  use  of  conversion  tables 
similar  to  the  code  conversion  tables  in  the  NAVCOSSACT  system,  pre¬ 
pare  queries  in  item  names  familiar  to  him.  The  system,  using  the  con¬ 
version  table,  will  substitute  the  coded  item  names  before  executing  the 
query.  This  feature  is  useful  if  the  data  in  the  file  is  received  in  a  coded 
form  or  if  the  data  was  coded  to  optimize  use  of  retrieval  logic. 


The  files,  which  look  much  the  same  as  COLINGO  files,  may  consist  of 
any  type  of  information  which  is  definable  to  the  system.  The  information 
can  range  from  small,  fixed-length  items  to  indexes  of  documents  and 
graphic  materials  containing  repeating  items  of  information  and  textual 
information.  It  is  a  system  which  was  designed  to  allow  the  user  flexi¬ 
bility  in  dealing  with  his  data.  Constraints  on  the  user  have  been  kept  at 
a  minimum;  he  is  not  limited  to  the  number  of  files  he  can  define  to  the 
system,  nor  is  he  committed  to  the  format  of  an  existing  file  in  the  event 
that  he  wants  to  change  that  format.  In  many  cases,  the  user  is  able  to 
accept  data  previously  undefined  to  the  FFS  into  his  system  without  new 
programming.  He  is  permitted  to  create  any  number  of  output  formats 
from  a  file  and  can  merge  information  from  a  number  of  files.  The  user 
has  a  logical,  English-like,  retrieval  language  at  his  disposal  with  which 
to  seek  out  the  answers  to  his  interrogations,  and  the  ability  to  format 
those  answers  in  a  variety  of  ways. 

The  Formatted  File  System  can  be  operated  on  any  IBM  1410  (or  7010} 
with  the  following  minimum  configuration: 
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*1  Central  processing  unit  -  80K  core  positions 
6  Magnetic  tape  units  (729) 

1  High-speed  pninter  (1403) 

1  High-speed  card  reader/punch  (1302) 

**1  1301  Disk  -  Mod  1 

The  program  system,  which  contains  approximately  32,  000  instructions, 
is  of  modular  design  and  contains  the  following  modules  interfaced  with 
the  IBM  1410/7010  operation  system: 

File  generation 
File  maintenance 
Retrieval 
Output 

File  Structure 

The  FFS  is  capable  of  processing  data  records  which  can  contain  three 
different  types  of  fields: 

1.  Fixed  Fields  -  which  occur  only  once  in  a  data  record  and 
occupy  a  fixed  position  within  the  record  relative  to  the 
intitial  character  of  the  record. 

2.  Periodic  Fields  -  which  can  occur  more  than  once  within  a 
data  record.  They  contain  a  category  of  data  which  is  repeti¬ 
tive  in  nature.  One  occurrence  of  related  but  different  periodic 
fields  is  termed  a  periodic  subset.  All  occurrences  of  a  sub¬ 
set  within  a  data  record  is  called  a  periodic  set. 

3.  Variable  Field  -  which  is  included  to  accept  qualitative  informa¬ 
tion  for  which  no  fixed  or  periodic  field  is  provided.  The  con¬ 
tents  of  the  variable  field  are  unrestricted.  The  length  is  limi¬ 
ted  only  by  the  data  record  size.  Each  data  record  is  limited  to 
one  variable  field. 


Original  system  was  programmed  at  40K  but  advanced  versions  re¬ 
quire  80K.  The  JSAFE  system  is  a  100K  version. 

sjcajc 

Optional  for  all  except  the  DLA/IDHS  Mod  1  version. 
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The  fixed  fields  appear  first  in  a  data  record,  followed  by  the  periodic 
fields,  and  terminating  with  the  variable  field. 

The  general  record  structure  is  subject  to  the  following  limitations: 


Maximum  number  of  characters  in  a  data  record  5400 

Maximum  number  of  field  definitions  per  record  299 

Maximum  number  of  periodic  set  definitions  per  record  3 

Maximum  number  of  characters  in  the  record  control 

field  30 

Maximum  number  of  characters  in  a  field  or  group  of 

contiguous  fields  to  be  referenced  collectively  52 

Maximum  number  of  subsets  within  any  periodic  set  599 


File  Maintenance 

The  FFS  has  the  capability  to  perform  the  following  file  maintenance 
functions: 

1.  Create  a  new  data  record  and  insert  it  into  the  specified  file. 

2.  Delete  an  existing  data  record  from  the  file. 

3.  Change  an  existing  data  field  (fixed  or  periodic)  within  an 

existing  data  record. 

4.  Add  a  periodic  subset  to  an  existing  data  record. 

5.  Delete  a  periodic  subset  from  an  existing  data  record. 

6.  Add  a  variable  field  to  an  existing  record. 

7.  Add  additional  information  to  the  existing  variable  field  of 

a  data  record. 

8.  Delete  the  entire  variable  field  from  a  data  record. 

In  all  the  file  maintenance  functions,  the  data  record  to  be  updated  is 
identified  by  the  record  control  field  (sort  key). 

The  FFS  will  accept  input  records  on  either  punched  cards  or  magnetic 
tape.  The  input  transactions  to  the  update  program  can  either  contain 
single  field  values  along  with  the  name  of  the  field  they  represent,  or 
they  may  be  packed  fields  described  to  the  system  by  a  separate  des¬ 
criptor  table. 


The  input  fields  can  be  accepted  in  the  input  format,  or  they  can  be 
edited  and  converted  by  use  of  tables  or  subroutines  specified  in  the  File 
Format  Table.  Updates  to  several  files  can  be  processed  during  a  given 
run. 

The  system  user  can  elect  either  of  two  options  to  record  the  results  of  a 
file  maintanance  run: 

1.  All  transactions  are  listed  with  the  "from"  and  "to"  values 
of  the  field(s)  affected  by  the  transaction.  Erroneous  trans¬ 
actions  which  have  not  been  effected  are  also  listed  with  a 
diagnostic  code  indicating  the  nature  of  the  error  (e.  g.  , 
attempt  to  change  a  non-existent  record). 

i  I 

2.  Only  the  erroneous  transactions  are  listed  with  their  diagnostic 
codes. 

Retrieval 

The  FFS  is  capable  of  retrieving  records  from  the  data  files  based  upon  a 
logical  combination  of  conditional  statements  about  the  values  contained  in 
the  fixed  and/or  periodic  fields  in  the  data  record.  The  general  form  of  a 
conditional  statement  is: 

(Logical  Connector),  (Field  Name),  (Operator),  (Data  Values) 

A  sample  query  with  three  statements  is: 

IF,  DAY  OR  YEAR,  IS  GREATER  THAN,  192, 

AND,  COUNTRY  NAME,  IS  EQUAL  TO,  CANADA, 

OR,  COUNTRY  NAME,  IS  EQUAL  TO,  UNITED  STATES,  MEXICO. 

Synonyms  may  be  substituted  for  field  names  and  operators.  Subroutines 
and  tables  may  be  specified  for  editing  and  converting  data  values  to  the 
data  file  format.  The  logical  connectors  permitted  are  IF,  AND,  OR. 

The  standard  operators  are: 
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EQUAL 
NOx  EQUAL 
LESS  THAN 

LESS  THAN  OR  EQUAL  TO 

GREATER  THAN 

GREATER  THAN  OR  EQUAL  TO 


In  addition  to  the  above,  the  FFS  allows  the  Overlap  (OVP)  operator, 
which  tests  to  determine  whether  a  convex  geometric  shape  (circle, 
polygon,  line  cr  point)  defined  in  the  query  statement  overlaps  a  con¬ 
vex  shape  f'V'  necessarily  the  same  type)  in  the  data  records.  The  FFS 
Query  Lai.t  -■ge  allows  one  level  of  parenthesis  in  the  combination  of  logi¬ 
cal  stauinvrts.  The  Condensed  Format  feature  allows  the  specification 
of  a  query  in  skeleton  form  followed  by  a  list  of  data  values;  the  values  are 
then  substituted  into  the  query  skeleton  and  executed  by  the  retrieval  pro¬ 
gram. 


Queries  can  be  batched  to  search  one  or  several  files  in  a  given  re¬ 
trieval  run. 


The  user  may  specify  that  the  results  of  his  retrieval  run  be  sorted  on  the 
values  contained  within  specified  fields  (fixed  or  periodic)  of  the  records. 
When  queries  are  levied  against  several  files,  the  retrieval  records  from 
the  different  files  may  be  sorted  on  values  common  to  the  different  files 
to  produce  a  multi-file  report. 


The  FFS  includes  the  capability  to  define  up  to  two  file  indexes  per  file. 
The  indexed  file  feature  improves  query  response  time  through  two  re¬ 
ductions  in  the  number  of  record  searches  per  run: 


The  Query  is  applied  only  against  data  records  identified  by 
the  file  index(es). 


2.  The  retrieval  program  passes  only  those  tape  reels  (in  the 

case  of  multi-reel  files)  which  contain  data  records  identified 
by  the  file  index(es). 


The  FICEUR  query  language  capability  is  similar  to  COLINGO’s  with  the 
following  differences: 


(1)  No  on-line  typewriter  input  capability  is  provided. 


(2)  All  elements  of  a  query  (operators,  item  names,  etc.)  must 
be  set  off  by  commas. 

(3)  One  level  of  parentheses  is  allowed.  (COLINGO  does  not  allow 
parentheses  within  a  query.) 

(4)  A  period  has  a  special  function  of  specifying  the  mode  of  logic, 
i.  e.  ,  whether  it  is  intra-  or  inter-record  logic. 

(5)  Capability  to  merge  files  is  provided. 

(6)  Capability  to  prepare  outputs  using  data  from  several  files 
is  provided. 

(7)  Circle  and  polygon  search  routines  are  provided.  It  is  possible 
to  do  the  equivalent  of  these  searches  in  COLINGO  by  using  the 
Great  Circle  Distance  subroutine  and  stored  queries,  but  not  via 
the  more  convenient  and  efficient  subroutines. 

(8)  Capability  to  order  data  records  retrieved  from  a  single  file  by 
employing  a  criteria  not  explicitly  in  the  data  records  is  pro¬ 
vided. 

Output 


The  FFS  contains  a  generalized  output  capability.  It  allows  the  production 
of  reports  on  any  combination  of  three  output  media: 

(1)  Printer  listing. 

(2)  Punched  cards. 

(3)  Fixed-length  magnetic  tape  records. 


The  user  can  control  the  output  format  by  specifying: 


(1)  Formatting  specifications  showing  the  position  of  the  data. 

(2)  Control  information  specifying  conditional  action. 

(3)  Data  manipulation  information  specifying  counts,  totals, 
subtotals,  and  integer  computations  within  a  record  or  across 
records. 
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(4)  Printed  report  pages  specifications  including  absolute  and  con¬ 
ditional  spacing,  skipping,  and  ejection  to  a  new  page. 

Printed  reports  consist  of  page  headers  and  trailers  and  one  or  more  types 
of  body  lines.  Body  lines  may  be  data  fields,  constants,  computed  values, 
or  combinations  of  the  three.  Fields  {either  data  or  computed  values)  may 
be  edited  to  remove  leading  zeros,  insert  decimal  points  or  other  charac¬ 
ters,  and  other  standard  editing  functions;  fields  may  also  be  converted  by 
use  of  special  purpose  subroutines  which  have  been  entered  into  the  system 

Punched  card  and  magnetic  tape  reports  may  contain  all  the  above  options 
except  those  unique  to  a  printed  report,  such  as  page  headers  and  trailers 
and  spacing,  skipping,  and  ejecting.  Magnetic  tape  reports  may  include 
several  types  of  records  with  the  restriction  that  all  records  be  the  same 
length.  The  record  length  may  be  specified  to  the  program  within  a  max¬ 
imum  value,  which  will  be  specified  at  each  installation  based  on  machine 
core  storage  size. 

The  Output  Program  also  contains  an  extract  option  which  allows  a  user 
to  output  data  from  a  file  without  defining  a  formal  output  format.  The 
user  identifies  the  desired  fields  by  name;  the  report  contains  a  tabulation 
of  the  specified  field  values  with  the  approved  field  labels. 

E.  THE  473L  SYSTEM 

System  473L  is  the  Headquarters,  United  States  Air  Force,  Command 
and  Control  System.  It  is  an  on-line  real-time  information  processing 
system  designed  to  facilitate  management  of  USAF  resources,  particu¬ 
larly  during  emergency  situations.  The  system  is  being  developed  in 
three  major  increments,  each  increment  having  successively  greater  capa¬ 
bility  relative  to  operational  scope,  equipment,  and  programs. 

The  initial  increment  (OTC)  utilized  an  IBM  1401  Data  Processor  subse¬ 
quently  replaced  by  an  IBM  1410  Data  Processor.  The  peripheral  equip¬ 
ment  included  an  IBM  1402  Card  Reader  Punch,  IBM  1301  Disk,  IBM 
7330  Tape  Drive,  IBM  729  Tape  Drives,  IBM  1415  Console  Inquiry  Sta¬ 
tion,  IBM  1403  Printer,  and  a  TRW  Computer  Communications  Console. 
The  second  increment  utilizes  a  Librascope  AN/FYQ-11  Data  Processor, 
ITT  AN/FYA-2  Integrated  Consoles,  Plotter  Tape  Transports,  IBM  1402 
Card  Reader  Punch,  and  an  Analex  Printer.  The  final  system  will  in¬ 
clude  a  second  set  of  the  aforementioned  equipments  which  will  provide  a 
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dual  system,  capable  of  sharing  the  work  load  and  of  providing  system 
back  up. 

Input  data  is  received  on-line  from  the  AUTODIN  network.  On-line 
staff  control  is  provided  for,  both  in  the  preliminary  screening  of 
AUTODIN  messages  and  in  the  control  of  outputs  at  the  individual  con¬ 
soles. 

The  473L  System  provides  support  to  the  Air  Staff  in  the  following  major 
functions:  situation  monitoring,  resource  monitoring,  plan  evaluation, 
plan  generation  and  modification,  and  operations  monitoring.  Support  is 
provided  to  each  of  these  functions  in  the  form  of  specific  operational 
capabilities.  An  operational  capability  is  a  set  of  interrelated  computer 
programs  designed  to  provide  a  console  operator  with  information  sup¬ 
porting  solutions  to  significant  and  predefined  problems  encountered  in  the 
exercise  of  USAF  responsibilities  for  evaluating,  modifying,  or  monitor¬ 
ing  plans  or  operations. 

Thus  a  central  473L  function  is  information  retrieval,  and  it  is  in  this 
area  that  its  major  contribution  to  system  flexibility  exists.  Two  major 
methods  of  communication  between  the  system  operator  and  the  data 
processing  subsystem  have  been  provided  in  the  473L  System.  The  first 
major  method  of  communication  is  the  operational  capability  overlay  -- 
a  plastic  mask  which  fits  over  the  Integrated  Console  Logic  Keyboard. 

This  mask  delineates  the  set  of  programs  related  to  a  specific  operational 
capability.  Operation  via  the  overlay  provides,  upon  activation  of  the 
logic  push  buttons,  an  indication  of  which  push  buttons  may  legally  be  acti¬ 
vated,  presents  a  cue  message  on  the  display,  allows  alpha  numeric  data 
to  be  entered,  and  responds  to  the  completed  cue  message  by  displaying 
a  follow-on  cue  message  or  a  data  output.-  In  this  manner,  the  operator 
can  exercise  a  choice  at  each  decision  point  and  is  led  in  a  step-by-step 
manner  through  the  procedures  necessary  to  obtaining  the  desired  infor  - 
mation.  The  console  employed  in  the  473L  system  is  the  TRW  Space 
Technology  Laboratories  Computer  Communication  Console.  (A  des¬ 
cription  of  the  capability  of  a  similar  console  is  that  of  the  Culler-Fried 
console  following). 

The  second  major  method  of  communication  is  via  the  Query  Language. 

The  Query  Language  is  a  quasi-English  language,  very  similar  to  the 
COLINGO  query  language,  which  enables  an  operator  to  retrieve  specific 
data  in  one  of  several  formats  from  any  system  file.  It  is  also  used 
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internally  by  all  other  programs  as  a  means  of  retrieving  data  from  the 
files. 

In  using  the  Query  Language,  the  operator  enters  his  query  directly  by 
means  of  the  typewriter  portion  of  the  Integrated  Consoles.  The  program 
interprets  the  statement,  makes  the  desired  retrieval,  and  formats  the  out¬ 
put.  -In  addition  to  direct  retrieval,  *he  Query  Language  includes  the  follow¬ 
ing  functions: 

.  Computation,  e.  g.  ,  summing  numerical  values. 

.  Logical  operations,  e.  g.  ,  finding  largest  or  smallest  values. 

.  Sorting  retrieved  data  for  output. 

.  Manipulating  files,  e.  g.  ,  combining  parts  of  two  files  into  one. 

.  Storing  and  recalling  frequently  used  query  statements. 

The  Query  Language  can  also  be  used  as  a  tool  for  system  programmers  in 
that  it  permits  a  sequence  of  operationally  related  statements  to  be  proces¬ 
sed  as  a  group,  has  very  powerful  file  reorganization  capabilities,  and  has 
variable  output  format  capabilities. 

Certain  noteworthy  characteristics  of  the  language  follow. 

The  language  allows  a  file  to  be  qualified  by  any  number  of  values  of 
attributes.  In  addition,  the  attributes  can  be  embedded  in  functions.  Thus, 
it  is  possible  to  ask  for  great  circle  distances  within  a  specific  distance 
of  some  point  in  a  single  query.  For  example: 

Retrieve  airfields  with  country  ■  Brazil,  GCD  (Brazilia^~2000). 

This  query  asks  for  airfields  in  Brazil  which  are  within  2000  miles 
of  the  city  Brazilia  by  the  great  circle  distance. 

Two  flexible  printouts  to  queries  such  as  this  are  provided.  One  has  a 
vertical  orientation  of  data  and  one  a  horizontal  orientation.  It  is  also 
possible  to  entitle  these  printouts,  such  titling  being  introduced  through 
the  query  language  statements.  Stored  statement  routines  are  also  avail¬ 
able  for  storing  completed  statements.  These  may  be  recalled  at  a  later 
time  for  additional  use.  As  part  of  this  capability  statements  with  built-in 
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blanks  can  be  stored  for  later  recall.  At  that  time,  the  particular  values 
appropriate  for  the  moment  can  be  filled  into  the  blanks  and  the  resultant 
statement  then  run.  This  insertion  of  values  into  blanks  is  accomplished 
through  the  aforementioned  Computer  Communication  Console.  This 
step  serves  to  illustrate  an  additional  source  of  473L  flexibility,  namely, 
the  complementarity  of  the  push-button  and  query  language  techniques, 
since  both  are  integrated  and  can  be  used  in  conjunction  with  each  other. 

The  473L  files  are,  like  its  query  language,  similar  to  the  COLINGO  files. 
Thus,  they  are  both  formatted  and  hierarchically  structured.  Several 
types  of  file  structures  are  allowed  in  the  47 3L  system,  mostly  to  make 
best  use  of  the  characteristics  of  the  storage  media;  for  example,  serial 
versus  random  access.  Examples  of  these  structures  are;  packed  data, 
blocked  data,  fixed  or  variable  length  entries,  and  combinations  of  these 
structures.  The  attributes  of  the  items  in  the  file  are  distinguished  by 
type;  such  as,  fixed  or  variable  length,  single  or  multiple  value,  etc. 

In  addition,  there  are  flexible  provisions  for  checking  and  internally  en¬ 
coding  the  file  data  as  desired.  The  system  also  maintains  a  data 
description  file  which  contains  all  information  required  to  process  the 
data  files.  This  data  description  file  is  part  of  a  generalized  file  mainten¬ 
ance  program  which  will  take  a  wide  range  of  possible  data  values,  con¬ 
vert  them  and  store  them  in  the  structured  data  base.  Both  the  data  and 
the  data  descriptions,  including  a  dictionary  of  all  external  versus  inter¬ 
nal  names,  are  kept  in  the  data  base.  Having  available  the  descriptors  and 
the  dictionary  as  well  as  the  data,  then,  the  query  language  can  effectively 
retrieve  as  well  as  store  data.  This  generalized  file  maintenance 
program  with  its  data  description  file  and  file  dictionary  corresponds 
to  the  COLINGO  file  dictionary  and  is  yet  another  source  of  system  flexibi¬ 
lity,  as  it  is  in  COLINGO. 

Some  capabilities  which  are  or  soon  will  be  part  of  the  473L  system  that 
COLINGO  does  not  have  are:  multiple  time- shared  user  consoles,  remote 
I/O,  priority  assessment  and  automatic  interruption  of  a  query  for  a  more 
important  task,  and  distinction  (and  even  simultaneous  use)  of  operations 
activity  and  training  exercises.  Most  of  these  capabilities,  however,  are 
advantages  to  be  gained  from  operation  on  a  larger  computer  under  a  more 
powerful  executive.  Therefore,  473L  and  COLINGO  are  essentially  com¬ 
parable  in  terms  of  information  system  flexibility  and  both  represent  an 
advanced  state-of-the-art  in  information  retrieval  system  design.  The 
major  advantage  that  473L  has  over  COLINGO,  is  not  so  much  in  terms  of 
system  flexibility  as  it  is  in  terms  of  efficiency,  473L  being  the  more 
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efficient  of  the  two.  This  is  best  exemplified  by  a  comparison  of  the 
two  query  languages.  Specifically,  qualification  of  a  data  record  in  473L 
can  depend  on  a  function  derived  from  several  property  values  in  the 
record.  (This  is  also  possible  in  NAVCOSSACT. )  This  can  be  done  in  a 
single  pass.  COLINGO,  in  contrast,  would  require  two  passes  of  the  file, 
one  pass  to  compute  the  function  based  on  the  appropriate  property  values, 
and  a  second  pass  to  determine  the  correct  qualification  from  the  computed 
values.  Similarly,  there  is  a  degree  of  efficiency  represented  by  the 
473L  (and  NAVCOSSACT)  SUM  operator  not  found  in  COLINGO.  This 
operator  permits  simultaneous  summing  of  several  properties  while  making 
only  one  pass  at  the  file.  These  two  examples  exemplify  the  greater  effi¬ 
ciency,  if  not  power,  of  the  473L  system. 

F.  THE  ACSI-MATIC  SYSTEM 

ACSI-MATIC  is  an  acronym  for  a  proposed  information  storage  and 
retrieval  system  which  was  to  be  designed  and  implemented  by  RCA  for 
the  Department  of  the  Army,  Assistant  Chief  of  Staff,  Intelligence.  It 
is  primarily  an  information  retrieval  system,  although  it  provides  a  good 
measure  of  generality  and  self-sustaining  control.  The  prototype  was 
implemented  on  a  Sylvania  9400  computer. 

The  system  was  intended  to  provide  a  common  repository  of  information 
which  could  be  used  by  intelligence  analysts  v.ith  different  area  respon¬ 
sibilities.  The  system  was  also  designed  to  reduce  the  amount  of  effort 
required  of  analysts  to  evaluate  and  file  new  information.  This  latter 
function  was  to  be  achieved  by  automatically  collating  new  and  old  infor¬ 
mation  on  the  basis  of  the  information  content.  All  information  stored 
was  to  be  indexed  as  thoroughly  as  possible  by  the  system  to  provide  the 
analysts  with  an  efficient  and  comprehensive  retrieval  capability. 

The  unit  of  information  storage  in  the  ACSI-MATIC  file  structure  was 
the  Information  Record  of  which  there  were  different  types,  such  as 
Military  Organization,  Personnel  and  Installation.  Data  coming  into  the 
system  might  be  logically  filed  in  more  than  one  type  of  Information 
Record.  All  data  filed  by  the  system  were  indexed  and  cross  referenced 
by  the  system.  Each  Record  type  had  a  set  of  allowable  information  that 
could  be  stored  in  it.  The  formation  of  new  information  records  was 
handled  both  explicitly  as  the  result  of  a  direct  order,  and  implicitly,  as 
a  result  of  a  gradual  acquisition  of  information. 
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To  provide  a  means  for  the  system  to  accept  and  manipulate  information 
without  excessive  external  coding  by  the  people  preparing  the  data  to 
be  input,  a  glossary  of  common  terms  was  stored  permanently  within 
the  system.  To  provide  information  to  the  system  about  the  relationships 
between  terms,  the  total  number  of  terms  was  sub-divided  by  the  users 
into  functional  categories.  A  glossary  was  set  up  for  each  category. 

In  general,  the  alphabetic  composition  of  a  term  contains  no  relational 
information.  Hence,  the  users  established  tree  structures  for  all  terms 
within  a  glossary.  The  position  of  a  term  in  the  tree  was  specified  by 
a  binary  code  called  Flexicode,  which  has  the  property  that  both  the  verti¬ 
cal  and  horizontal  coordinates  of  a  term  are  well  specified.  Further,  given 
any  two  codes,  a  third  code  cam  always  be  inserted  between,  in  either 
direction.  An  entry  in  a  glossary,  therefore,  is  a  pair;  namely,  an 
English  term  and  an  associated  Flexicode.  The  glossaries  are  maintained 
in  alphabetic  order. 

The  aforementioned  Flexicodes  are  maintained  in  "hierarchical"  order 
in  the  Hierarchy  Index  List.  Each  entry  in  the  list  contains  the  Flexi¬ 
code  for  the  term  it  represents,  plus  a  pointer  to  each  Information 
Record  in  the  file  containing  information  about  the  term. 

The  system  receives  messages  and  orders  from  the  analysts  by  way  of  a 
paper  tape  reader.  System  responses  were  on  a  monitor  typewriter  and 
high  speed  printer.  All  elements  of  information  in  a  message  or  order 
were  tagged  tc  make  them  identifiable  by  the  system.  For  example,  infor¬ 
mation  about  an  individual  would  be  handled  as  folio  vs; 

PER::  NAM::  SMITH,  JOHN  H.  ::  JOB::  CIVIL  ENGR::  AGE:  42:: 
The  tag  PER  identifies  the  type  of  information  being  dealt  with  - 
personnel.  The  tag  PER  has  a  number  of  allowable  sub-tags,  including 
NAM,  JOB,  AGE,  with  obvious  meanings.  The  character  is  a 
delimiter  to  make  scanning  easier. 

Each  message  or  order  also  contained  information  about  the  message 
(order}  and  the  data  contained  therein.  Examples  of  these  are: 

.  Name  of  person  putting  in  data 

Source  document  identification 

Source  document  data 
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Security  classification. 

Orders  were  designed  to  provide  the  analysts  with  the  capability  to 
explicitly  define  some  types  of  system  processing.  These  included: 

.  Establish  a  new  Information  Record 

.  Change  an  Information  Record 

.  Perform  Thesaurus  Maintenance 

.  Report  (print  any  of  a  number  of  standard  reports) 

.  Query  (interrogate  the  system  files  in  complex  manner)  . 

Messages  were  designed  to  be  the  method  of  adding  new  information  to  the 
system  files  on  a  continuous  basis.  It  was  not  necessary  for  the  person 
preparing  the  message  to  know  anything  about  the  state  of  the  system 
files,  but  only  to  properly  format  and  tag  the  information  being  entered. 

An  initial  data  base  of  known  information  was  to  be  entered  using  analyst 
orders.  For  each  Information  Record  type  there  were  criteria  to 
determine  when  new  types  were  to  be  established  as  data  were  received. 
Each  element  of  information  filed  in  the  system  was  cross  referenced  as 
thoroughly  as  possible.  For  example,  data  input  via  an  analyst  order 
established  a  Record  for  an  installation  at  location  L.  Part  of  the  data 
kept  with  this  Record  was  a  list  of  all  technical  personnel,  which  included 
the  name  Smith,  J.  H.  .  At  the  time  the  order  was  given  and  Record 
established,  a  reference  to  the  Record  was  made  in  the  Hierarchy  Index 
List  entry  for  Smith  J.  H.  At  a  later  time  some  information  entered 
the  system  via  a  message  which  reported  that  a  Smith,  J.  H.  ,  a  civil 
engineer,  had  been  given  an  award  for  outstanding  work.  In  the  List 
entry  for  Engineer,  Civil,  a  reference  was  then  made  to  Smith,  J.  H. 
and  conversely,  under  Smith,  J.  H.  a  reference  made  to  Engineer, 

Civil.  The  system  now  had  two  pieces  of  information  about  Smith,  J.  H.  : 
(1)  he  was  at  location  L;  (2)  he  was  a  civil  engineer.  At  some  point  there 
might  be  enough  information  on  Smith  to  warrant  the  establishment  of  a 
Record,  type  Personnel,  for  Smith.  If  this  was  done,  the  List  entry  for 
Smith  would  point  to  the  Record  of  the  installation  at  L  and  to  the  Record 
for  Smith.  The  List  entry  for  Engineer,  Civil  would  also  point  to  these 
Records.  The  previous  references  which  were  only  to  the  name  Smith  and 
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the  name  Engineer,  Civil  were  thus  replaced  by  references  to  collections 
of  information  about  each  name.  This  example  illustrates  the  dynamic 
quality  of  the  files  which  were  intended  to  grow  as  a  function  of  the  data 
being  input  without  explicit  orders  from  the  analysts.  The  decision 
making  processes  and  the  actual  indexing  procedures  were  more  complex 
than  those  illustrated. 

The  system  was  designed  to  handle  complex  Boolean  expressions  which 
specified  retrieval  requirements.  Basic  retrieval  operations  involved 
manipulating,  when  possible,  the  indices  rather  than  the  data  during 
the  selection  process.  For  example,  consider  the  query,  "List  all  civil 
engineers  at  installation  at  location  L.  "  The  List  entry  for  Engineer, 

Civil  has  a  pointer  to  the  List  for  each  man  known  to  be  a  civil  engineer. 
Each  of  these  entries  has  references  to  the  Records  which  contain 
information  about  the  man  named.  These  references  are  the  disc  loca¬ 
tions  of  the  Information  Records.  The  installation  at  L  has  a  Record 
stored  at  a  known  disc  location.  Therefore,  if  this  address  appears  in 
a  List  entry  for  a  man  known  to  be  a  civil  engineer,  he  is  known  to  be 
at  installation  L. 

The  programming  system  for  ACSI-MATIC  was  composed  of  an  input- 
command  package,  an  executive  control  package,  an  input-output  package, 
and  a  collection  of  utility  packages. 

The  input-command  package  accepted  and  interpreted  commands  for  the 
execution  of  major  system  functions  and  for  establishing  the  appropriate 
programs  to  effect  the  execution  of  those  functions. 

The  executive  control  package  for  ACSI-MATIC  furnished  a  collection  of 
functions  to  enable  the  linking,  loading,  binding,  and  execution  of  system 
tasks.  In  addition,  functions  to  enable  parallel  processing  up  to  sixty-four 
tasks  and  dynamic  allocation  (i.  e.  ,  requests  for  more  space  generated  at 
execution  time)  were  available.  Basic  blocks  for  loading,  linking,  and 
parallel  processing  control  were  kept  in  terms  of  chains  of  descriptions; 
i.  e.  ,  lists  of  descriptive  information  were  organized  via  chain  links  to 
reflect  program  relations,  resource  allocations,  and  priority  for 
execution. 

The  ACSI-MATIC  programming  system  furnished  to  the  user  a  variety  3f 
utility  packages.  For  example,  requests  for  retrieval  of  items  from  the 
disc  file  by  name  were  accepted  and  handled  by  the  Thesaurus  Access 
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Package.  In  addition  to  retrieving  data  from  the  files  by  name  via 
indices,  this  package  furnished  all  of  the  machinery  for  adding  and 
deleting  entities  of  the  files.  Techniques  for  interlocking  accessing  during 
maintenance  and  for  preserving  accessed  information  in  core  for  sub¬ 
sequent  use  were  developed. 

A  second  utility  package  was  a  comprehensive  sort-merge  package  which 
was  available  to  the  user.  This  program  allowed  sorting  on  the  basis 
of  complex  user-furnished  ordering  criteria. 

A  programming  Tmguage  and  an  assembly  program  were  also  developed. 
The  assembly  produced  relocatable  code  and  sufficient  descriptive  infor¬ 
mation  to  satisfy  the  requirements  of  the  dynamic  allocation  and  linking 
algorithms. 
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PART  III.  MAN-MACHINE  INTERFACE  SYSTEMS 


In  this  section  systems  which  have  concentrated  on  the  enhancement  of 
man/machine  communication  through  the  development  of  various  types  of 
response  techniques  are  discussed.  Each  of  the  systems  mentioned  herein 
has  contributed  to  man/machine  interface  techniques  either  by  introducing 
a  new  dimension  along  which  communication  can  occur,  or  else  by  develop¬ 
ing  new  techniques  for  improving  the  communication  along  familiar  dimen¬ 
sions.  Thus,  SKETCHPAD  has  added  the  graphical  dimension  to  computer 
interfacing  and  BASEBALL  has  demonstrated  the  feasibility  of  using  ordi¬ 
nary  English,  albeit  of  a  constrained  variety,  as  a  query  language.  The 
Culler-Fried  and  JOSS  Systems,  in  contrast,  have  introduced  new  techniques 
for  enhancing  communication  along  a  familiar  dimension  of  man/machire 
communication,  namely  mathematics.  In  each  case  it  is  important  to  note 
that  the  system  designers  had  in  mind  a  wide  class  of  users  operating  with¬ 
in  a  broad  spectrum  of  problem  areas.  Thus,  the  techniques  they  have  in¬ 
troduced  are  quite  general  in  nature  and  of  wide  potential  use. 

A.  SKETCHPAD 

The  development  of  SKETCHPAD  marks  an  advance  in  the  exploration  of  the 
dimensions  along  which  an  operator  may  communicate  with  the  computer. 

The  particular  dimension  explored  by  SKETCHPAD  is  graphical  and  the 
basic  aim  of  the  system  has  been  to  make  rapid  interaction  between  man 
and  machine  possible  through  graphical  means.  SKETCHPAD  is  fundamen¬ 
tally  a  drawing  system  which  has  been  implemented  on  the  TX-2  computer 
at  the  M.  I.  T.  Lincoln  Laboratory.  It  places  at  the  disposal  of  the  user 
"paper"  in  the  form  of  a  cathode  ray  tube  and  "ink"  in  the  form  of  a  hand¬ 
held  photo-cell  called  a  light-pen.  In  addition,  it  places  at  the  user’s 
disposal  a  multitude  of  graphical  operations  which  enhance  his  ability  to 
make  complicated  line  drawings  from  relatively  simple  subparts.  It  pro¬ 
vides  the  user  with  the  ability  to  copy  his  light-penned  drawings  onto  a 
permanent  pen  ana  ink  plotter.  Finally,  the  SKETCHPAD  system  has  as¬ 
sociated  with  it  a  tape  library  in  which  previously  drawn  figures  may  be 
stored  for  later  use. 
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A  SKETCHPAD  drawing  sequence  may  typically  begin  with  the  operator 
pointing  the  light  pen  at  the  display  system  and  simultaneously  using  a 
''draw"  button,  "draw"  being  one  of  the  primitive  functions  provided  by 
the  system.  The  computer  then  constructs  a  straight-line  extending  from 
the  point  the  light  pen  originally  identified  to  whatever  subsequent  point 
has  been  chosen  by  the  user.  The  user  does  not  employ  the  light  pen  as  he 
might  a  pencil  and  ruler.  He  simply  identifies  an  initial  point  and  activates 
the  "draw"  function.  The  computer  then  constructs  the  line.  In  particular, 
when  the  "draw"  button  is  pressed,  the  computer  sots  up  two  end  points 
and  a  line  segment  in  storage.  One  of  the  end  points  remains  attached  to 
the  light  pen,  however,  and  the  subsequent  pen  motions  move  this  second 
point.  This  action  of  establishing  pairs  of  points  and  a  line  segment  in 
store  may  be  repeated  several  times.  Thus,  to  construct  an  hexagonal 
figure  one  would  repeat  the  operation  six  times,  once  for  each  side  of  the 
figure.  In  order  to  close  the  lines  into  a  six  sided  figure,  it  is  merely 
necessary  to  return  the  light  pen  to  a  point  near  the  end  of  the  first  line 
drawn.  The  figure  will  automatically  close  on  itself.  The  drawing  may  then 
be  terminated  by  a  control  on  the  light  pen. 

In  this  fashion  an  irregular  hexagon  has  been  constructed.  A  better  view 
of  the  range  and  scope  of  SKETCHPAD  can  be  gained  when  one  attempts 
to  construct  a  regular  hexagon.  To  construct  a  regular  hexagon,  use  can 
be  made  of  the  irregular  hexagon  just  constructed  and  other  primitive  func¬ 
tions  available  in  SKETCHPAD.  To  make  the  irregular  hexagon  regu’ar, 
one  could  employ  the  following  strategy,  f  n?  dep;  esses  a  '  circle  center" 
button  while  identifying  a  center  with  the  light  pen.  Then  o:.e  identifies  a 
subsequent  ;.oint  to  mark  a  radius  and  presses  the  "draw"  button.  SKETCH¬ 
PAD  will  construct  an  accurate  circle.  Having  established  a  circle,  one 
may  point  to  a  corner  of  the  irregular  hexagon  and  then,  by  depressing  a 
"move"  button,  bring  one  corner  of  the  hexagon  ir^o  the  circle.  The  lines 
converging  at  that  corner  will  follow  the  light  pen  in  rubber  band  fashion 
into  the  previously  drawn  circle.  Each  corner  may  be  thus  moved  inside 
the  circle  and  the  irregular  hexagon  can  thus  be  circumscribed. 

To  make  the  hexagon  regular,  one  points  to  one  side  of  the  nexagon,  de¬ 
presses  a  "copy"  button  and  points  to  another  side.  SKETCHPAD  will 
then  produce  a  regular  hexagon,  if  possible,  e.fter  five  such  repetitions. 

A  depression  of  a  "delete"  button  erases  the  circle,  and  the  user  has  con¬ 
structed  a  regular  hexagon. 
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Thus,  several  primitive  functions  have  been  identified  and  illustrated, 
namely  "draw,  "  "center  circle,  "  "move,  "  "erase,  "  "copy,  "  etc.  With 
these  functions  an  irregular  nexagon  was  constructed  and  from  it,  a 
regular  hexagon.  Subsequent  use  of  these  and  similar  functions  make  it 
possible  to  construct  extremely  large  hexagonal  mosaic  patterns  such  as 
one  might  find  on  hexagonal  graph  paper,  for  example.  A  professional 
draftsman  would  require  two  day3  to  construct  a  900  hexagon  mosaic  on 
a  30  in.  by  30  in.  plotter.  Including  the  time  to  decide  upon  the  above 
strategy,  SKETCHPAD  required  only  half  of  an  hour.  The  example  just 
discussed  illustrates  the  fundamental  way  in  which  use  of  SKETCHPAD 
differs  from  normal  pen  and  ink  drawing.  In  the  above  example  the  user 
created  a  rough  approximation  of  a  figure  and  then,  by  the  addition  of  con¬ 
straints  to  that  figure,  relied  upon  the  computer  to  systematically  apply 
those  constraints  to  each  pa  .  of  the  initial  rough  figure.  It  is,  in  fact, 
the  contention  of  the  SKETCHPAD  designer  that  this  process  of  a  rough 
approximation  followed  by  the  imposition  of  new  conditions  is  essentially 
the  design  process  that  any  designer  might  go  through  in  the  creation  of  a 
finished  design  from  a  basic  idea.  As  new  requirements  are  created, 
SKETCHPAD  supplies  the  mechanical  means  whereby  those  requirements 
may  be  imposed  upon  that  which  has  been  done,  thus  relieving  the  de¬ 
signer  of  much  of  the  detailed  work  required  by  the  imposition  of  the 
newer  constraints. 

The  various  design  activities  for  which  SKETCHPAD  may  be  used  are, 
perhaps,  obvious.  Thus,  it  is  of  utility  in  the  production  of  highly  repe¬ 
tition  drawings,  drawings  where  accuracy  is  required.  Moreover,  it  has 
been  demonstrated  in  drawing  mechanical  systems  such  as  linkage  suspen¬ 
sions  and  in  manipulating  them  to  observe  the  resultant  motions. 

In  addition,  the  use  of  SKETCHPAD  as  an  input  program  for  other  compu¬ 
tation  programs  is  suggested.  Thus,  with  this  system,  truss  bridge  de¬ 
signs  can  be  generated  with  designated  load  points  specified.  Subsequent 
processes  can  compute  the  resultant  forces  based  upon  the  truss  bridge 
design  and  the  specified  loads.  In  this  fashion  SKETCHPAD  can  be  made 
an  engineering  design  tool.  Similarly,  the  use  of  SKETCHPAD  in  circuit 
design  is  certainly  suggested,  though  the  computation  required  by  electro¬ 
nic  circuitry  goes  beyond  the  capacity  of  SKETCHPAD  at  the  moment. 

The  SKETCHPAD  Program,  which  was  written  over  a  one  year  period  and 
required  approximately  one  and  a  half  m..n-years  of  effort,  comprises 
12,000  words  of  executable  program,  20,000  words  of  ’ring  structure* 
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p.  i,,tt  >  \\  *i  •  ,  *i‘  .  000  words  of  input  -output  buffer.  The  TX-2 

■  '  i  in  wtrcn  it  operates  is  a  single-address,  binary  digital  com- 

V  iter  w  th  an  unusually  large  memory.  It  is  an  experimental  machine, 
however,  and  as  such  contains  certain  distinctive  features.  These  are: 

(1)  simultaneous  use  of  in-out  machines  through  interleaved  programs; 
and  (2)  flexible,  ’configured*  data  processing.  In  addition,  the  TX-2  in¬ 
cludes  automatic  memory  and  arithmetic  overlap,  a  ’bit’ -sensing  in¬ 
struction  (the  operand  is  one  bit),  addressable  arithmetic  element  regis¬ 
ters,  64  indeA.  registers,  indirect  addressing  and  magnetic  tape  auxil¬ 
iary  storage. 

In  summary,  the  use  of  SKETCHPAD  exists  in:  (1)  making  small,  system¬ 
atic  changes  in’existing  drawings;  (2)  in  gaining  scientific  and  engineering 
understanding  of  operations  that  can  be  described  graphically;  (3)  as  a 
topological  input  device  for  complex  patternings  such  as  required  by  net¬ 
works  and  circuitry;  (4)  for  highly  repetitive  drawings  requiring  re¬ 
cursively  generated  sub-pictures  has  been  demonstrated.  That  the  system 
has  been  made  to  draw  electrical,  mechanical  and  even  animated  drawings 
qualifies  it  as  a  general-purpose,  user-on-line, man-machine  communica¬ 
tion  technique. 

B.  BASEBALL 

Whereas  SKETCHPAD  demonstrated  the  feasibility  of  man/machine  com¬ 
munication  through  the  medium  of  graphical  display,  BASEBALL  may  be 
viewed  as  demonstrating  the  feasibility  of  man/machine  communication 
through  the  medium  of  a  relatively  flexible  query  language,  flexible  with 
respect  to  the  typical  query  language  available  in  contemporary  retrieval 
systems  such  as  those  discussed  in  Part  II.  The  query  language  of  the 
BASEBALL  system  is,  in  fact,  a  small,  but  nonetheless  varied  subject  cf 
ordinary  English.  And  since  every  potential  user  of  a  system  can  be  sup¬ 
posed  to  know  this  subset  already,  there  exists  with  respect  to  the  BASE¬ 
BALL  user  no  requirement  for  training  in  its  query  language.  Thus  any¬ 
one  who  speaks  English  and  is  familiar  with  baseball  can  query  the  system 
with  a  minimum  of  training. 

BASEBALL  is  a  computer  program  that  answers  questions  posed  in  ordin¬ 
ary  English  about  data  in  its  files.  The  program  consists  of  two  parts. 

The  linguistic  part  reads  the  question  from  a  punched  card,  analyzes  it 
syntactically,  and  determines  that  information  which  is  given  about  the 
data  being  requested.  The  second  part,  the  processor,  searches  through 
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the  data  for  the  appropriate  information,  processes  the  results  of 
the  search,  and  prints  out  the  answer. 

The  program  is  written  in  IPL-V,  an  information  processing  language 
that  uses  lists,  and  hierarchies  of  lists,  called  list  structures,  to  repre¬ 
sent  information.  Both  the  data  and  the  dictionary  are  list  structures,  ir, 
which  items  of  information  are  expressed  as  attribute -value  pairs,  e.g. 
Team  -  Red  Sox. 

The  program  operates  in  the  context  of  baseball  data.  At  present,  the 
data  are  the  month,  day,  place,  teams  and  scores  for  each  game  in  the 
American  League  for  one  year.  In  this  limited  context,  a  small  vocabu¬ 
lary  is  sufficient,  the  data  is  simple,  aid  the  subject-matter  is  familia*  . 

Considerable  flexibility  is  permitted  in  the  wording  and  the  form  of  input 
questions.  The  program  accepts  any  grammatical  question  that  is  made 
up  from  words  found  in  the  BASEBALL  dictionary,  and  that  adheres  to 
the  following  restrictions.  Questions  are  limited  to  a  single  clause.  By 
prohibiting  structures  with  dependent  clauses  the  syntactic  analysis  is 
considerably  simplified.  Logical  connectives,  such  as  and,  or  and  not 
are  also  prohibited,  as  are  constructions  implying  relations  like  most  an 
highest.  Finally,  questions  involving  sequential  facts,  such  as  "Did  the 
Red  Sox  ever  win  six  games  in  a  row?  "  are  prohibited.  The  designers 
note  that  within  these  restrictions,  complete  freedom  is  allowed  with 
regard  to  word  order,  phraseology,  verb  voice,  etc.  ,  and  that  the  user 
is  free  to  achieve  considerable  variety  and  complexity  in  question  format 
There  is  considerable  leeway  between  simple  questions  such  as  "Who  did 
the  Red  Sox  lose  to  on  July  5?  "  and  more  complex  questions  such  as  "Di 
every  team  play  at  least  once  in  each  park  in  each  month?  "  Some  sampl 
questions  that  the  program  handles  successfully  are: 

Did  every  team  play  all  of  the  teams  at  least  once  in  May  1959? 

Had  any  team  scored  more  than  8  runs  by  May  15? 

How  many  games  were  lost  by  a  2  run  margin  to  the  A's? 

What  were  Detroit’s  winning  margins  at  home  before  June  1959? 

What  were  the  scores  of  the  Senators  losing  home  games? 

How  often  did  Baltimore  beat  New  York  at  home  in  August? 

How  many  home  games  did  New  York  lose  in  June  by  one  run? 

When  did  the  Red  Sox  win  by  more  than  7  runs? 
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The  concept  of  the  specification  list  is  fundamental  to  the  operation  of 
the  BASEBALL  program.  This  list  can  be  viewed  as  a  canonical  ex¬ 
pression  for  the  content  of  the  question.  It  represents  the  information 
contained  in  the  question  in  the  form  of  attribute-value  pairs  such  as 
Team  •  Red  Sox.  The  spec  list,  which  is  generated  from  the  question 
by  the  linguistic  part  of  the  program,  governs  the  operation  of  the 
processor.  For  example,  the  question  "Where  did  the  Red  Sox  play  on 
July  7?  "  has  the  specification  list: 


Place 

=  ? 

Team 

-  Red  Sox 

Month 

=  July 

Day 

=  7 

The  dictionary  definitions,  which  are  expressed  as  attribute -value  pairs, 
are  used  by  the  linguistic  portion  of  the  program  in  generating  the  spec 
list.  A  complete  definition  for  a  word  or  idiom  indudes  a  part  of  speech, 
for  use  in  determining  the  phrase  structure  of  the  question;  a  meaning,  for 
use  in  analyzing  content;  an  indication  of  whether  the  entry  is  a  question- 
word,  e.  g.  ,  who  or  how  many;  and  an  indication  of  whether  a  word  occurs 
as  part  of  any  stored  idiom. 

The  meaning  of  a  word  can  be  expressed  in  one  of  several  forms.  It  may 
be  a  main  or  derived  attribute  with  an  associated  value.  For  example,  the 
meaning  of  the  word  l  earn  is  Team  =  (blank),  the  meaning  of  Red  Sox  is 
Team  ■  Red  Sox,  and  the  meaning  of  who  is  Team  -  ?  .  The  meaning  may 
designate  a  subroutine,  together  with  a  particular  value,  as  in  the  case 
of  modifiers  such  as  winning,  any,  six,  or  how  many.  Some  words  have 
more  than  one  meaning;  the  word  Boston  may  mean  either  Place  s  Boston 
or  Team  «  Red  Sox.  The  dictionary  entry  for  such  words  contains,  in 
addition  to  each  meaning,  the  designation  of  a  subroutine  that  selects  the 
appropriate  meaning  according  to  the  context  in  which  the  word  is  en¬ 
countered.  Finally,  some  words  such  as  the,  did,  play,  etc.  ,  have  no 
meaning. 

For  testing  of  the  system,  the  BASEBALL  data  are  organized  in  a  hier¬ 
archical  structure,  like  an  outline,  with  each  level  containing  one  or 
more  items  of  information.  Relationships  among  items  are  expressed 
by  their  occurrence  on  the  same  list,  or  on  associated  lists.  The  main 


57 


heading,  ov  highest  level  of  the  structure,  is  the  attribute  Month.  For 
each  month,  the  data  are  further  subdivided  by  place.  Below  each  place 
under  each  month  is  a  list  of  all  games  played  at  that  place  during  that 
month.  The  complete  set  of  items  for  one  game  is  found  by  tracing  one 
path  through  the  hierarchy,  i.  e.  ,  one  list  at  each  level.  Each  path  con¬ 
tains  values  for  each  of  six  attributes,  e.  g.  : 

Month  *  July 


Place 

Day 

Game  Serial  No. 

(Team 

(Team 


Boston 

7 

96 

Red  Sox,  Score  5  ) 
Yankees,  Score  s  3) 


The  parentheses  indicate  that  each  Team  must  be  associated  with  its  own 
score,  which  is  done  by  placing  them  together  on  a  sublist. 


The  processing  routines  are  written  to  accept  any  organization  of  the 
data.  In  fact,  they  will  accept  a  non-parallel  organization  in  which,  for 
example,  the  data  might  be  as  above  for  all  games  through  July  31,  and 
then  organized  by  place,  with  month  under  place,  for  the  rest  of  the 
season.  The  processing  routines  will  also  accept  a  one-level  structure  in 
which  each  game  is  a  list  of  all  attribute -value  pairs  for  that  game.  The 
possibility  of  hierarchical  organization  was  included  for  generality  and 
potential  efficiency. 

The  BASEBALL  program  is  organized  into  several  successive,  essentially 
independent  routines,  each  operating  on  the  output  of  its  predecessor  and 
producing  an  input  for  the  routine  that  follows.  The  linguistic  routines 
include  question  read-in,  dictionary  look-up,  syntactic  analysis,  and 
content  analysis.  The  processing  routine  include  the  processor  and  the 
responder. 


In  the  question  read-in  routine,  a  question  for  the  program  is  read  into 
the  computer  from  punched  cards.  The  question  is  formed  into  a  sequential 
list  of  words. 
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In  the  dictionary  look-up  stage,  each  word  on  the  question  list  is  found 
in  the  word  dictionary  and  its  definition  is  copied.  Undefined  words  are 
printed  out.  The  list  is  then  scanned  for  possible  idioms;  contiguous 
words  that  form  an  idiom  are  replaced  by  a  single  entry  on  the  list, 
and  an  associated  definition  from  the  idiom  dictionary,  a  separate 
dictionary,  is  entered  beside  it.  At  this  point,  each  entry  on  the  list  has 
associated  with  it  a  definition  which  includes  a  part  of  speech,  a  meaning 
and  certain  other  indicators,  such  as  sub-routine  markers,  etc. 

The  syntactic  analysis  is  based  on  the  parts  of  speech,  v.hich  are  syn¬ 
tactic  categories  assigned  to  words  for  use  by  the  syntax  routine.  There 
are  14  parts  of  speech  and  several  ambiguity  markers. 

First,  the  question  is  scanned  for  ambiguities  in  parts  of  speech,  which 
are  resolved  in  some  cases  by  examining  the  adjoining  words,  and  in  other 
cases  by  inspecting  the  entire  question. 

Next,  the  syntactic  routine  locates  and  brackets  the  noun  phrases,  the 
prepositional  phrases  and  the  adverbial  phrases.  The  verb  is  left  un¬ 
bracketed. 

Following  the  question  hi  ■  1  •  <*•  >irtge,  a  rou-  determines  whether  the 

verb  is  active  or  passive.  !  ms  routine  ins-'  s.  >  the  lust  two  verbal  ele¬ 
ments  in  the  question,  and  nets  a  verh-vou  .  marker  t-.r  use  later  in  the 
program.  Next,  the  subj«  >.  t  and  ob|i-<  t  of  '  orb  i.  ocated  and  labelled. 
This  routine  makes  use  of  bracketing  into-  ■  M  A  •  order  and  verb- 

voice  in  order  to  determine  subject  .>*.  .  •  i<  1  c  lu|M  m  the  question. 

Finally,  the  syntactic  analysis  .  ms-,  to  see  if  any  of  the  words  is  marked 
as  a  question  word.  If  not,  a  >.gn*l  is  set  to  indicate  that  the  question 
requires  a  yes /no  answer. 

The  confer.*  analysis  stage  uses  the  dictionary  meanings  and  the  results 
of  the  syntactic  analysis  to  set  up  a  specification  list  for  the  processing 
program.  F.rst  subroutines  arc  executed  which  have  been  inserted  in  the 
dictionary  look-up  stage.  Here  ambiguities,  such  as  whether  Boston  is  a 
team  or  a  place,  are  resolved  Also  attribute-value  pairs  are  modified 
in  appropriate  ways.  Thus,  what  team  becomes  Team  •  ?  in  this  portion. 
Similarly  Team  -  (blank)  in  the  phrase  each  team  is  altered  to  Team  r  each. 
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After  the  subroutines  have  been  executed  the  question  is  scanned  to 
consolidate  those  attribute -value  pairs  that  must  be  represented  on  the 
specification  list  as  a  single  entry.  Next,  successive  scans  will  create 
any  sublists  implied  by  the  syntactic  structure  of  the  question.  Finally, 
the  composite  information  for  each  phrase  is  entered  onto  the  specifica¬ 
tion  list.  Depending  on  its  complexity,  each  phrase  furnishes  one  or  moi 
entries  for  the  list.  The  resulting  specification  list  is  printed  in  outline 
form,  to  provide  the  questioner  with  some  intermediate  feedback. 

The  next  stage  is  the  processor  stage.  The  previously  prepared  specific 
tion  list  indicates  to  the  processor  the  part  of  the  sorted  data  which  is 
relevant  for  answering  the  input  question.  The  processor  selects  the 
relevant  subset  of  data,  and,  in  stages  if  necessary,  culls  from  it  the 
information  the  spec  list  requests.  The  processor  produces  this  answer, 
in  the  form  of  a  list  structure,  for  the  last  stage,  the  responder. 

The  core  of  the  processor  is  a  search  routine  that  attempts  to  find  a 
match,  on  each  path  of  a  given  data  structure,  for  all  the  attribute -value 
pairs  on  the  specification  list;  when  a  match  for  the  whole  specification 
list  is  found  on  a  given  path,  these  pairs  relevant  to  the  specification  list 
are  entered  on  a  found  list.  A  particular  specification  list  pair  is  con¬ 
sidered  matched  when  its  attribute  has  been  found  on  a  data  path  and,  eitl 
the  data  value  is  the  same  as  the  spec  value,  or  the  spec  value  is  ?  or  ea 
in  which  case  any  value  of  the  particular  attribute  is  a  match. 

The  found  list  produced  by  the  search  routine’  3  hierarchical  list  struc'. 
containing  one  main  or  derived  attribute  on  each  level  cf  each  path.  Eacl 
path  on  the  found  list  represents  the  information  extracted  from  one  or 
more  paths  of  the  data.  Each  path  on  the  found  list  may  thus  represent 
a  condensation  of  the  information  existing  on  many  paths  of  the  search  da 

No  attempt  has  yet  been  made  to  respond  in  grammatical  English  sentenc 
Instead,  the  final  found  list  is  printed,  in  outline  form.  For  questions 
requiring  a  yes/no  answer,  YES  is  printed  along  with  the  found  list.  If 
the  search  routine  found  no  matching  data,  NO  is  printed  for  yes/no  ques 
tion,  and  NO  DATA  for  all  other  cases. 

Questions  which  are  raised  by  the  BASEBALL  program  but  not  answered 
concern  the  feasibility  of  list  structures  when  dealing  with  data  bases 
that  contain  hundreds  of  files,  and  not  just  one  file  as  in  the  BASEBALL 
program.  If  list  structures  are  not  feasible,  then  the  specification  list 
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would  have  to  be  drastically  changed.  Further,  no  experimentation  is 
at  present  available  to  determine  whether,  g,ven  a  choice  between  a  sub¬ 
set  of  ordinary  English  and  some  typical  query  language  such  as  the 
COLINGO  language  or  the  473L  query  language,  the  user  would  choose 
the  English  subset. 

The- relevance  of  the  BASEBALL  program,  therefore,  from  the  point  of 
view  of  computer  usage  is  that  it  underscores  the  necessity  for  consider¬ 
ing  ordinary  English  and  its  attendant  translational  difficulties  along  with 
the  more  traditional  kinds  of  query  languages  and  their  attendant  trans¬ 
lational  difficulties  when  confronted  with  the  problem  of  computer  control 
through  some  access  language. 

C.  DIRECT  ENGLISH  ACCESS  AND  CONTROL  (DEACON) 

The  Direct  English  Access  and  Control  (DEACON)  system  is  an  experi¬ 
mental  information  retrieval  system  designed  by  GE  TEMPO.  Its 
goal  has  been  to  demonstrate  the  feasibility  of  computer  control  through 
a  system  that  the  designers  term  "largely  unconstrained  English.  " 

In  this  sense,  then,  the  DEACON  work  may  be  viewed  as  a  continuation 
of  the  aforementioned  BASEBALL  effort. 

The  DEACON  "breadboard,  "  the  first  designer’s  model  to  come  out  of 
this  effort,  consists  of  a  set  of  programs  and  data  for  the  GE  225  com¬ 
puter.  The  current  data  base  contains  3000  items  which  are  accessed 
by  4C0  words  of  vocabulary  of  which  100  are  purely  function  words.  This 
ratio  of  1:4  is  expected  to  increase  to  1:20  in  a  future  system  with  a  pro¬ 
jected  vocabulary  of  40,  000  words. 

The  DEACON  breadboard  data  base  is  list  structured  and  the  principle 
routines  and  syntactic  -  semantic  rules  are  programmed  in  LAP,  a  list¬ 
processing  language  developed  at  GE. 

The  strategy  for  accessing  the  list  structured  data  base  is  contained  in 
the  designer’s  treatment  of  the  syntactic -semantic  rules.  In  BASEBALL 
a  sentence  is  first  analyzed  by  the  syntactic  analysis  routine  to  determine 
its  grammatical  structure  and  then  is  analyzed  by  the  content  analysis 
routine  to  provide  that  sentence  with  a  "semantic"  reading  which  is 
meaningful  with  respect  to  the  data  base.  This  content  analysis  routine 
is  programmed  in  terms  of  the  explicit  format  of  the  data  base  and  is 
dependent  on  this  format.  In  DEACON,  on  the  other  hand,  the  syntactic 
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analysis  is  merged  with  the  semantic  analysis  into  a  single  stage  and 
each  input  sentence  is  subjected  to  a  semantic  analysis  which  provides 
a  syntactic -semantic  reading,  with  respect  to  the  DEACON  data  base. 

It  is  noteworthy,  however,  that  both  the  sequence  "Is  the  Forrestal  in 
London?  "  and  the  sequence  "In  London  Forrestal?  "  mean  the  same  thing 
.in  the  DEACON  system. 

Thus,  whereas  the  BASEBALL  program  was  syntactically  too  constrainet 
the  DEACON  program  is  syntactically  too  unconstrained,  at  least  with 
respect  to  its  professed  goal  of  ordinary  English. 

The  syntactic -semantic  analysis  routines  are  written  in  forms  of 
generalized  types  of  data  structures,  the  final  identification  of  which  is 
made  in  terms  of  the  specific  sentence  being  analyzed.  As  a  consequent 
DEACON  is  less  dependent  upon  a  rigid  data  base  format. 

The  similarities  between  BASEBALL  and  DEACON  are  striking.  Both 
make  use  of  list- structures  and  list  processing  languages.  Both  are  off¬ 
line  with  sentences  introduced  on  punched  cards.  Both  are  accessed  and 
controlled  by  ordinary  English,  though  of  varying  degrees  of  constraint. 
Both  contain  dictionary  look-up,  semantic  and  syntactic  analyses  and 
search  routines  based  upon  the  results  of  the  preceding  routines  and 
finally  print-out  routines  which  present  the  resu' 1  of  the  search  routines 
to  the  user.  The  major  differences  between  the  two  programs  are  the 
collapsing  in  DEACON  into  a  single  stage  of  two  separate  stages  in 
BASEBALL,  namely  the  syntactic  and  semantic  stages,  and  the  greater 
dependence  in  the  one  (BASEBALL)  than  in  the  other  (DEACON)  on  a  rigi 
data  base  format. 

Problems  which  remain  for  the  one  system,  therefore,  remain  for  the 
other.  These  problems  are  (1)  how  to  effect  efficient  file  up-dating; 

(2)  how  to  effect  efficient  access  in  data  bases  storing  25,000  files  and 
not  just  one  file;  and  (3)  how  to  generate  new  files. 

D.  JOHNNIAC  OPEN  SHOP  SYSTEM  (JOSS) 

JOSS  is  an  experimental  on-line  computational  system  developed  by  the 
RAND  Corporation  as  a  problem-solving  tool  for  its  scientific /engineer¬ 
ing  personnel.  The  system  has  two  separate  functions,  each  of  which 
can  be  used  together  or  apart.  The  first  of  these  functions  is  that  of 
an  elaborate  printing  desk  calculator.  Thus  JOSS  can  add,  subtract, 
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multiply  and  divide.  It  can  compute  exponents,  square  roots  and  trigo¬ 
nometric  functions.  Further,  it  is  possible  to  request  the  fraction, 
integer,  digit  and/or  exponent  part  of  a  number.  Logarithms  are  to  the 
base  e  in  JOSS  and  decimals  carried  to  the  ninth  place. 

Requests  for  all  of  these  functions  can  be  made  simply  and  easily  once 
the  user  has  familiarized  himself  with  the  keyboard  symbols  for  the 
various  JOSS  arithmetic  functions.  Thus  by  typing  in  ’2  +2',  JOSS 
replies  '4'.  Similarly,  * / *  will  cause  JOSS  to  divide,  '.  *  to  multiply 
and  an  to  raise  to  an  exponent.  Thus  'TYPE  3*3’  will  cause  JOSS  to 
r^ply  '3*3=  27.  *  The  expression  *  TYPE  sqrt  (81)'  will  cause  JOSS  to 
reply  'Sqrt  (8  1):  9',  i.  e.  ,  the  square  root  of  81.  B>  enclosing  the 
number  to  be  square  rooted  in  parentheses,  it  is  possible  to  build  up 
complex  expressions.  Thus  'TYPE  sqrt  (sqrt(2*2,'!2))'  will  cause  JOSS  to 
reply  'sqrt  (sqrt(2*2*2))  =  2‘. 

All  of  these  functions  can  be  expressed  in  a  single  complex  function,  of 
course,  and  in  a  very  short  time  it  is  possible  for  the  user  to  master 
the  'calculator'  function  in  JOSS. 

The  second  function  in  JOSS  is  that  it  can  also  act  as  a  'stored-program' 
computer.  This  means  that  it  is  possible  to  enter  a  statement  in  JOSS 
and  have  it  stored  away  for  later  use.  Thus,  by  prefixing  a  statement  with 
an  identifying  number,  JOSS  is  thereby  instructed  to  store  away  the  se¬ 
quence  following  the  prefixed  number  and  to  be  ready  to  recall  that  sequent 
oh  demand.  A  typical  statement  to  be  entered  as  a  stored  program  state¬ 
ment  is: 


1.  1  Type  X,  sqrt  (x),  log  (k),  exp  (x). 

JOSS  will  store  this  information.  A  subsequent  command  will  cause  JOSS 
to  execute  the  statement  to  whatever  value  of  X  the  user  requires.  Thus 
the  statement: 

Do  step  1.  1  for  X=l(l}100 

instructs  JOSS  to  take  the  values  of  X  as  being  from  1  to  100.  JOSS  will 
begin  to  compute  the  square  root,  log  and  exponent  of  each  number  from  1 
to  100  as  specified  in  the  stored  program  statement  1.  1  above. 
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It  is  possible  at  any  time  to  interrupt  JOSS  and  specify  a  format  in 
which  the  output  of  some  stored-program  statement  is  to  be  printed. 

Thus,  the  JOSS  user  can  have  the  various  values  arranged  in  a  matrix 
with  each  number  from  1  to  100  at  the  head  of  a  row  and  each  function  to 
be  computed  at  the  head  of  a  column.  Demands  for  spacing  can  also  be 
introduced.  Thus,  JOSS  cam  be  requested  to  insert  a  blank  line  every 
five  or  ten  lines,  etc. 

It  is  also  possible  to  name  formats  which  have  been  defined  by  the  user 
and  to  request  that  the  output  of  some  stored-programs  be  printed  in 
the  defined  format  which  can  thus  be  reviewed  by  name.  A  typical  state¬ 
ment  with  format  specified  is: 

1.  1  Type  X,  sqrt  (x),  log  (x),  exp  (x)  in  form  1. 

It  is  worthwhile  to  note  that  JOSS  is  primarily  used  as  a  combination  of 
its  two  functions,  namely  as  a  desk  calculator  in  combination  with  a  stored- 
program  computer.  This  is  largely  because  these  combined  functions 
allow  the  user  constantly  to  exercis  s  judgment  during  a  session  on  JOSS. 
This  he  does  by  initiating  a  program,  interrupting  it,  changing  it,  altering 
its  format,  re-specifying  its  values  and  its  functions  and  so  on.  Numerous 
error  messages  as  well  as  techniques  to  avoid  catastrophic  errors  resulting 
in  loss  of  prior  work  are  abundantly  supplied. 

The  JOSS  system  operates  solely  in  the  interpretive  mode.  This  is  to 
say,  with  each  input  statement  from  a  remote  typewriter,  it  picks  up  the 
statement,  scans  it,  executes  it  immediately  and  then  proceeds  to  the 
next  statement.  JOSS  is  able  to  complete  this  cycle  on  the  average  of  15 
times  every  second.  Because  JOSS  is  time-shared  (there  are  eight  remote 
consoles),  the  user  is  occasionally  requir’d  to  wait.  The  maximum  period 
a  user  would  have  to  wait,  when  the  system  is  being  used  to  full  capacity, 
is  sixteen  seconds. 

The  amount  of  space  allotted  to  each  JOSS  user  is  quite  small,  about  a 
page  per  user.  This  is  due  to  two  factors,  the  first  being  the  limitations 
of  the  Johnniac  computer,  an  old  and  rather  small  vacuum  tube  machine. 

The  second  reason  for  space  limitations,  however,  is  that  the  JOSS 
designers  were  simply  not  interested  in  large  memory  capacity.  Thus 
JOSS  was  intended  for  users  with  small  problems  who  would  take  maximum 
advantage  of  the  problem-solving  capability  of  a  machine  with  which  it 
was  possible  to  interact  easily  and  quickly.  Production  computing 
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interaction  of  the  sort  attainable  with  larger  more  capacious  machines 
was  neither  desired  nor  sought  after  by  the  JOSS  designers.  Now  that 
the  interaction  capability  has  been  demonstrated,  however,  attempts  to 
increase  computation  space  per  user  as  well  as  the  number  of  possible 
simultaneous  users  are  in  process. 

The  goal  of  JOSS  to  develop  a  tool  for  problem  solving,  rather  than 
production  computing,  has  been  oriented  toward  the  design  of  hardware 
and  software  for  a  specific  application,  namely  scientific  and  engineering 
computation.  In  the  design  of  this  hardware/software  package  speed  and 
power  have  been  sacrificed  for  smooth  operation  and  a  relatively  trans¬ 
parent  algebraic  user’s  language.  In  this  sense,  then,  JOSS  is  like 
STRESS  and  COGO  discussed  in  Part  IV.  However,  JOSS  differs  in 
that  the  applications  class  that  it  addresses  itself  to,  viz.  ,  general 
scientific  and  engineering  computation,  is  less  restrictive  than  the 
applications  class  encompassed  by  STRESS  and  COGO.  Secondly,  JOSS 
represents  an  integrated  software/hardware  design  oriented  toward  a 
specific  application  whereas  STRESS  and  COGO  are  strictly  software 
systems  executed  on  a  conventional  machine,  the  IBM  7090. 

A  major  limitation  of  JOSS  is  that  at  the  end  of  a  session  on  the  machine 
the  program  vanishes.  Subsequent  operation  at  a  later  date  on  the  same 
program  requires  complete  re-entry  of  the  entire  program. 

E.  TRW  TWO-STATION,  ON-LINE  SCIENTIFIC  COMPUTER  (OLSC) 
(ALSO  "CULLER-FRIED  SYSTEM") 

The  Culler-Fried  System  is  a  computer  program  developed  by  TRW  Space 
Technology  Laboratories  for  the  RW  400  Computer  and  Display  Analysis 
Console  to  provide  a  tool  for  the  on-line  investigation  of  scientific/ 
engineering  problems  which  can  be  stated  in  terms  of  classical  mathe¬ 
matics. 

Three  principal  features,  independent  but  interacting,  characterize  the 
system: 


Functional  Orientation 


The  programming  structure  is  such  that  in  the  computer,  as  it 
appears  to  the  user,  functions  (sets  of  101  points)  rather 
than  individual  numbers  constitute  the  data  elements  while  the 
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repertoire  of  "commands"  consists  of  operations  on  functions 
(e.  g.  ,  arithmetic,  differential,  and  integral  operations). 

Control  and  Display  Capability 

Central  to  the  operation  of  the  system  is  a  control  console 
having  a  number  of  push  buttons  or  key&,  which  allow  for  user 
control  of  the  computer,  and  two  17-inch  CRT  oscilloscopes 
(with  line-drawing  capability)  which  provide  direct  graphical 
representation  of  computational  results.  An  8-inch  CRT  with 
alphanumeric  capability  and  a  Flexowriter  provide  numerical 
output  when  required. 

Console  Programming 

A  simple  procedure  allows  the  us>  r  to  construct,  directly  at 
the  console,  new  subroutines,  using  as  building  blocks  an 
initial  set  of  hand  programmed  subroutines,  plus  any  sub¬ 
routines  previously  created  by  this  console  programming 
procedure. 

The  system  incorporates  two  standard  keyboards,  one  associated  with 
operators,  the  other  with  operands  plus  a  keyboard  for  digit  entries. 
Each  operation  is  carried  out  by  pushing  a  single  key  of  the  operator 
keyboard.  These  operations  may  be  at  any  of  a  variety  of  logical  levels, 
for  example: 

(1)  Basic  machine  language  commands; 

(2)  Elementary  arithmetic; 

(3)  Functional  mathematics; 

(4)  Basic  display  opera. ions; 

(5)  System  management  and  data  transfer  operations. 

Since  a  complete  system  includes  all  of  these  levels,  it  was  convenient 
to  associate  all  keys  with  operations  for  any  one  level,  w  ith  a  simple 
means  for  changing  "levels,"  i.  e.  ,  changing  en  masse  the  significance  of 
all  the  operator  keys.  A  small  subset  of  operator  keys  designated  as 


66 


'level  indicators,  "  analogous  to  case  shift  on  a  typewriter  is  used  to 
effect  level  changes.  Corresponding  to  the  variety  of  operator  levels, 
there  is  a  similar  diversity  in  the  nature  of  the  "operands.  "  In  t^e 
context  of  level  2,  for  example,  they  are  treated  as  ordinary  numbers, 
while  in  the  context  of  level  3  they  are,  as  explained  above,  functions 
(represented  by  their  values  at  101  points).  Each  key  on  the  operand  key¬ 
board  corresponds  to  a  storage  allocation  in  some  mass  storage  device, 
such  as  magnetic  drum  or  disc,  and  data  transfers  between  thic  -uid 
the  computer  are  effected  with  the  operator  keys  LOAD  and  STORE. 

If  A  is  the  label  on  a  particular  operand  key,  then  pushing,  in  sequence, 
the  operator  key  LOAD  and  the  operand  key  A  brings  the  data  "in"  A  -- 
be  it  a  number,  a  vector,  or  any  other  list  --  into  the  computer's 
magnetic  core  memory,  while  pushing  the  keys  STORE  A  accomplishes  the 
converse. 

Experience  with  this  system  has  shown  the  on-line  approach  to  be  of 
most  help  in  so-called  "fixed  point"  problems,  i.  e.  ,  those  which  have 
the  form 


f  -  Tf 

where  f  is  an  unknown  function  to  be  determined  (or  ,  equally  well,  sever¬ 
al  functions)  and  T  is  an  operator  sufficiently  complicated  in  structure 
(non-linear,  singular,  etc.)  to  cause  difficulties  in  both  analytic  and 
numerical  approaches.  The  designation  "fixed  point"  is  associated  with 
the  concept  of  f  as  a  "point"  in  "function  space,  "  and  T  as  a  mapping  of 
that  space  onto  itself. 

If,  by  any  means,  one  can  find  an  f  such  that  the  operation  T  f  repro¬ 
duces  f,  one  has  clearly  a  solution  of  the  above  equation.  The  on-line 
system  with  its  graphical  display  facility  and  light  pen  in  essence  makes 
it  convenient  to  explore  the  function  space  in  search  of  a  fixed  point. 
Because  of  its  unusual  flexibility,  the  system  facilitates  an  experimental 
approach  in  which  the  strategy  of  the  search  in  the  function  space  is  varied 
by  the  user  on  the  basis  ox  the  information  he  obtains. 
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Certain  shortcomings  of  the  Culler-Fried  system  have  been  noted. 

For  example,  there  is  no  way  for  a  user  to  examine  the  sequence  of  sub¬ 
routine  steps  which  constitute  the  operations  performed  by  a  button. 

The  user  must  therefore  document  his  subroutines  with  pencil  and  paper. 
Future  efforts  are  being  initiated  to  remedy  such  difficulties. 
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PART  IV.  SPECIAL  PURPOSE  PROGRAMMING  SYSTEMS 


In  this  section  two  special  purpose  problem-oriented  language  systems 
are  discussed.  Each  of  these  languages  and  associated  computer 
programs  illustrates  an  aooroach  to  problem  solving  which  gains  in 
flexibility  and  ease  of  use  precisely  because  the  problem  areas  addres¬ 
sed  are  extremely  narrow  and  highly  specific.  Thus  STRESS  is  a 
problem-oriented  language  that  can  be  used  by  structural  engineers  as 
an  aid  in  describing  the  kinds  of  calculations  which  must  be  performed  in 
almost  every  structural  problem.  Heretofore,  these  calculations  had 
to  be  performed  manually,  or  else  described  with  difficulty  in  FORTRAN- 
like  languages.  The  fact  that  the  problem  area  is  highly  constrained 
coupled  with  the  willingness  on  the  part  of  the  designer  to  sacrifice 
generality  for  the  sake  of  ease  of  use  by  the  engineer  enables  designers 
of  problem-oriented  language  systems  to  provide  extremely  satisfactory 
tools  for  specific  classes  of  users.  It  is  not  surprising  that,  in  the 
light  of  the  extreme  specificity  of  each  problem-oriented  language,  there 
is  little  or  no  carry  over  from  one  problem  class  to  another. 

A.  STRUCTURAL  ENGINEERING  SYSTEMS  SOLVER  (STRESS) 

STRESS  is  a  special  purpose  programming  system  designed  as  a  machine 
aid  to  engineers  in  the  solution  of  structural  engineering  problems  on 
a  digital  computer.  The  STRESS  system  consists  of  a  special  purpose 
language  in  which  a  structural  problem  can  be  easily  and  naturally 
described.  Further,  STRESS  cortains  an  associated  processor,  or 
compiler,  which  accepts  well-formed  problem  statements  in  the  STRESS 
language  and  ultimately  produces  appropriate  solutions. 

The  STRESS  programming  s/stem,  according  to  its  designers,  should  not 
be  viewed  either  as  a  general-purpose  program  nor  a  compiler  in  the 
conventional  sense.  Instead,  they  note  that  it  combines  features  of 
both.  Thus,  they  explain  that  from  the  point  of  view  of  the  user,  STRESS 
resembles  a  compiler  in  that  it  consists  of  a  source  language  unintelligible 
to  the  computer  and  a  processor  which  translates  the  source  language 
into  machine-coded  operations.  However,  unlike  most  compilers, 
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STRESS  makes  no  provision  for  the  compilation  of  an  "object 
program.  " 

A  typical  STRESS  problem  is  one  in  -which  the  nature  and  size  of  a 
particular  structure,  say,  the  frame  of  some  building,  is  specified, 
along  with  the  loads  that  the  structure  is  to  be  subjected  to,  a  statement  of 
the  procedure  to  be  followed  in  the  solution,  and  a  statement  of  the 
results  desired.  Modification  of  any  of  this  information  may  also  be 
requested  in  order  to  obtain  additional  results  for  slightly  altered  pro¬ 
blems. 

A  STRESS  input  consists  of  problem-oriented  statements  using  common 
engineering  terminology.  In  the  STRESS  language  the  difference  between 
data  statements  and  procedural  statements  has  been  obliterated  and  the 
majority  of  statements  contain  both  data  and  process  directives. 

The  STRESS  input  involves  a  specification  of  a  particular  problem.  The 
full  specification  contains:  (1)  a  header  statement  which  initiates  the 
routine  and  provides  a  title;  (2)  a  series  of  size  descriptors  which  state 
the  size  of  the  problem  to  be  handled  in  terms  of  numbers  of  joint,  sup¬ 
ports, members  and  loadings:  (3)  a  statement  of  the  procedure  to  be  used 
in  solving  the  problem;  (4)  a  set  of  structural  data  descriptors  within 
which  it  is  possible  to  specify  necessary  information  about  the  geometry, 
topology,  mechanical  properties  and  the  presence  of  local  releases 
(hinges,  roller,  etc.)  of  the  structure;  (5)  a  set  of  statements  which  per¬ 
mit  rapid  evaluation  of  alternate  designs;  and  (6)  a  set  of  termination 
statements . 

Within  the  framework  of  these  statements  the  designers  of  STRESS  have 
tried  to  maintain  communication  in  the  engineers  language  while  providin 
a  concise  form  of  input.  The  result  is  a  relatively  easy-to-use  special 
purpose  programming  language  and  problem  solving  system  tailor-made 
to  the  needs  of  the  structural  engineer. 

The  internal  system  of  STRESS  performs  four  basic  functions:  (1)  input, 

(2)  compilation,  (3)  execution,  and  (4)  modification.  The  input  phase  is 
initiated  by  the  header  statement  mentioned  above  and  is  terminated  by  th 
termination  statement,  a  phrase  such  as  SOLVE,  or  SOLVE  THIS  PART. 
These  and  all  statements  in  between  are  presented  to  the  computer  (an  IB 
709/7090/7094  data  processing  system  with  32,768  storage  locations) 
through  punched  card  inputs.  The  initial  phase  includes  scanning  of  the 
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punched  cards  for  the  identification  of  the  various  parts  of  the  program; 
that  is,  the  labels  and  the  data  in  the  form  of  numerical  values.  This 
information,  once  identified,  is  stored  and  the  parameters  specified  by 
the  labels  are  set  and  other  appropriate  preliminary  steps  undertaken. 

At  this  point  if  any  portion  of  the  statement  is  unacceptable,  an  identi¬ 
fying  error  message  is  printed  out.  The  designers  have  tried  to  provide 
as  much  diagnostic  information  as  possible.  * 

In  the  second,  or  compiling  phase,  all  editing,  checking  and  compilation 
functions  are  performed.  Additional  error  checks  are  performed,  and  if 
the  problem  is  found  to  be  executable,  the  remaining  compilations  are 
performed. 

In  the  execution  phase,  a  control  program  essentially  calls  in  and 
executes  the  appropriate  sub-routines,  checks  again  for  errors,  and  ter¬ 
minates  if  an  error  occurs.  After  execution  the  system  returns  again 
to  input  phase. 

In  the  modification  phase,  the  input  phase  is  resumed,  such  resumption 
being  triggered  by  a  key  phrase  in  the  initial  input  statements.  In  this 
phase  the  modification  statement  is  examined  to  determine  the  appropriate 
actions  to  be  performed  and  these  actions  are  executed  with  the  modified 
information  being  superimposed  on  or  merged  with  the  previous  data. 

An  unlimited  number  of  modifications  are  allowed. 

From  this  brief  description  of  STRESS  it  should  be  apparent  that  the 
STRESS  system  amounts  to  an  extremely  useful  and  flexible  programming 
language  for  use  in  a  highly  structured  problem  environment,  namely 
that  of  structural  engineering.  The  strategy  behind  the  creation  of 
STRESS  has  been  the  development  of  a  special  purpose  language  tailored 
to  the  needs  of  a  specific  user  and  so  constructed  as  to  be  easily  trans¬ 
lated  into  machine  control.  The  purpose  of  STRESS  is  not  the  enhancing 
of  computer  r  -age  through  greater  generality  of  programs  and  program 
structures  however.  Rather  it  is  to  facilitate  the  use  of  digital  computers 
for  the  solution  of  structural  engineering  problems. 

B,  COGO-90 

COGO-90  is  the  name  of  a  civil  engineering  problem  oriented  language 
and  programming  system.  The  basic  difference  between  COGO-90  and 
STRESS,  is  essentially  in  the  problem  environment  to  which  each  addresses 
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itself.  Hence,  COGO-90  is  used  in  the  solution  of  geometric  problems 
arising  out  of  land  surveying,  highway  design  and  bridge  geometry, 
whereas  STRESS  deals  with  structural  engineering  problems.  Thus 
COGO-90,  like  STRESS,  is  a  useful  and  flexible  programming  language 
for  use  in  a  highly  specific  problem  environment.  And  its  purpose  has 
been,  like  STRESS,  solely  to  facilitate  the  use  of  digital  computers  in 
highly  specific  problem  area. 

The  COGO  program  currently  runs  on  the  IBM  1620  computer,  and 
executes  simple  macro  calls  on  functions  in  coordinate  geometry.  It 
accepts  as  input  sequences  of  macro  calls  with  specified  parameters. 
These  macros  are  functions  normally  used  by  civil  engineers  to  calcul 
areas,  point  coordinates,  line  lengths,  etc.  ,  in  support  of  field  sur¬ 
veying  and  similar  problems.  Any  logical  sequence  of  macros  may  be 
used.  All  calculations  may  be  printed  out.  Some  typical  COGO  functi. 
are  illustrated  below. 

STORE  51  2000.0  5000.0 

(Record  the  point  known  as  n51"  as  having  coordinates  x  =  2000, 
y-5000). 

LOCATE/AZIMUTH  22  51  2236.07  116  34  00 

(Record  point  "22"  as  being  2236.  07  feet  from  point  51  at  an 
azimuth  of  116°34,00".  Record  and  output  the  coordinates  of 
point  22). 

Similarly,  angles,  areas  and  other  information  can  be  declared  or 
derived  from  existing  data.  COGO  is  designed  to  be  used  primarily  b' 
engineers  working  from  a  plot  plan  who  desire  quick  answers  to  one-s 
surveying  problems.  COGO  is  not  capable  of  extensions  except  by  di 
coding  new  macro  functions.  While  relatively  unsophisticated,  COGO 
a  useful  and  inexpensive  engineering  tool. 

COGO-90  was  developed  for  the  IBM  709,  7090  and  7094  computers, 
is  based  on  the  original  COGO  system  developed  by  C.  L.  Miller  for  1 
IBM  1620.  In  addition  COGO  versions  have  been  or  are  being  develop 
for  the  IBM  7040,  7070  and  705,  the  CDC  1600  and  3600,  the  Burrougl 
5000  and  the  PDP  6. 


COGO-90  occupies  approximately  20K  of  core;  it  contains  several  hun¬ 
dred  FAP  instructions  and  several  thousand  FORTRAN  instructions. 

The  program  required  approximately  1  man  year  to  develop.  However, 
a  large  number  of  the  COGO-90  programs  were  identical  to  those  of  the 
1620  version.  Indeed,  it  is  estimated  that,  were  COGO-90  written  with¬ 
out  the  benefit  of  1620  COGO,  it  would  have  taken  from  three  to  five  years 
to  develop. 
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PARTY.  TIME -SHARING  SYSTEMS 


The  ability  of  a  system  to  time -share  (i.  e.  ,  to  make  a  computing 
facility  available  to  a  multiplicity  of  users  simultaneously)  is  a  mode, 
or  aspect,  of  operation  of  a  system;  it  is  essentially  independent  of  the 
area  of  application,  or  other  features  of  the  system  and  can  be  achieved 
in  several  ways.  It  is  similar,  in  this  respect,  to  the  user-on-line 
mode  of  operation  and,  in  fact,  most  time- sharing  systems  are  also 
(at  least  partly)  user-on-line  systems,  though  the  converse  is  not  gener 
ally  true.  Time-sharing  systems  have  been  built  with  widely  different 
properties  and  features,  and  the  determination  of  the  most  suitable  set 
of  features  for  a  system  must  be  made  without  regard  to  whether  or  not 
the  system  will  be  made  to  time-share.  By  way  of  indicating  the  range 
of  computing  facilities  that  have  been  time-shared,  consider  the  JOSS 
system  discussed  in  Part  III.  The  facility  made  available  to  the  user 
is  essentially  that  of  an  elaborate,  responsive  desk  calculator.  In  con¬ 
trast  to  this  is  the  MAC  system  which  gives  the  user  access  to  a  comple 
IBM  7094  which  he  may  use,  wisely  or  poorly. 

The  main  question  concerning  time-sharing  is  whether  or  not  it  should 
be  done,  and  if  so,  how.  The  matter  of  the  relative  efficiency  of  time¬ 
sharing  versus  batch  processing,  for  example,  is  still  an  open  issue. 
However,  many  types  of  computing  centers,  particularly  university 
environments,  have  found  time -sharing  to  be  the  best  way  to  make  a  cor 
puter  available  to  a  large  number  of  users.  Time-sharing  seems  justi¬ 
fied,  even  desirable,  where  many  short,  one-shot  programs  are  involve 
where  nearly  equal  computer  time  is  to  be  given  to  each  user;  and  whert 
no  real-time  requirements  on  t.ie  system  might  be  compromised.  In 
other  cases,  it  may  be  preferable  to  use  a  more  elaborate  multi-progra 
ming  scheme  with  user  priorities,  or,  alternatively,  a  simple  batch 
processor. 

Certain  extra  hardware  (and  therefore  extra  expense)  is  required  in  a 
time-sharing  system.  For  user-on-line  operation,  users’  stations  sue! 
as  typewriters,  display  consoles,  etc.  ,  must  be  provided;  and  in  genera 
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sufficient  buffering,  control,  and  I/O  channel  capacity  must  be  available. 

A  prime  requirement  for  time -sharing  is  fool-proof  memory  protection, 
whether  it  be  done  by  software  --  i.  e.  ,  interpretive  execution,  as  in 
JOSS  --  or  hardware,  as  it  must  be  for  an  efficient  large-scale  system. 
Given  this  required  hardware,  almost  any  computer  system  can  be  made 
to  time-share.  In  fact,  simple  forms  of  time-sharing  occur  as  a  matter 
of  course  *'n  some  of  the  general  purpose  systems  examined  in  Part  VI. 

Among  the  major  concerns  of  the  time-sharing  designer  are  the  develop¬ 
ment  of  proper  algorithms  for  scheduling,  the  development  of  routines 
capable  of  restoring  programs  interrupted  at  some  prior  stage  to  their 
proper  place  in  the  computer  upon  being  recalled  by  the  user,  the  develop¬ 
ment  of  sufficiently  sophisticated  executive  routines  to  minimize  the  delay 
time  experienced  by  the  user  between  his  input  and  the  system's  response. 
Thus,  the  time-sharing  designer  is  concerned  with  generalization  of  his 
computer  in  the  sense  in  which  it  is  available  to  a  large  number  of  users 
simultaneously.  Other  considerations  of  generality,  however,  such  as 
increasing  the  dimensions  along  which  man/machine  communication  is 
possible,  or  enhancing  the  flexibility  of  program-linkage  techniques,  or 
extending  the  range  of  problem  areas  the  computer  is  capable  of  handling, 
may  also  be  objectives  of  time-shared  projects.  Indeed,  many  time¬ 
sharing  system  designers  believe  that  the  use  of  time-sharing  system 
techniques  is  the  only  way  in  which  tools  such  as  JOSS,  SKETCHPAD,  and 
Culler-Fried  will  ever  be  economically  feasible.  Two  such  projects  are 
described  below. 

A.  PROJECT  MAC 

The  system  goal  of  Project  MAC  is  regarded,  by  its  designers,  as  the 
development  and  operation  of  a  community  utility  capable  of  supplying 
computer  power  to  several  users  simultaneously  with  the  least  number  of 
constraints.  Thus,  the  MAC  system  is  viewed  as  a  public  utility  which 
provides  each  of  its  users  with  *he  equivalent  of  a  private  computer  whose 
capacity  is  adjustable  to  individual  needs. 

The  primary  terminals  of  the  MAC  system  are  40  model  35  Teletypes  and 
28  IBM  1050  teletypewriters. 

Each  can  dial,  through  the  M.I.  T.  private  branch  exchange,  either  the 
IBM  7094  installation  of  Project  MAC,  or  the  similar  installation  of  the 
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M.I,  T.  Computation  Center.  The  supervisory  program  of  the  two 
computer  installations  accepts  or  rejects  the  call.  Each  installation  car 
provide  service  to  as  many  at  24  simultaneous  users. 

To  provide  long  distance  access,  the  MAC  system  is  connected  to  the 
TELEX  network  operated  by  the  Western  Union  Company  and  will  be 
connected  shortly  to  the  TWX  network  operated  by  the  American  Telephi 
and  Telegraph  Corporation.  The  TWX  terminal  can  reach  approximately 
65,000  Teletypes,  and  the  TELEX  network  provides  access  from  termi¬ 
nals  in  Europe  as  well  as  in  the  United  States. 

The  heart  of  the  MAC  system  is  the  Compatible  Time  Sharing  System 
(CTSS),  a  programming  and  executive  system  which  allows  for  multiple 
user  access  while  also  permitting  conventional  batch-processing  loads 
to  be  run.  This  is  one  of  the  principal  design  feattires  of  the  CTSS. 

The  CTSS  includes  executive,  scheduling,  debugging,  assembler-compil 
and  input-output  facilities.  The  programming  languages  presently  avail* 
able  in  the  system  for  the  use  of  individuals  are  FAP,  FORTRAN,  MAD 
COMIT,  LISP,  SLIP,  a  limited  version  of  ALGOL  or  two  problem-orien 
languages  for  Civil  Engineering,  COGO  or  STRESS. 

The  system  will  continue  to  add  new  language  facilities  and  other  utility 
programs  and  programming  aids. 

The  users  of  the  MAC  system  include  faculty  and  students  of  a  dozen 
academic  departments,  and  research  staffs  of  five  major  research 
laboratories.  The  disciplines  represented  range  from  engineering  to 
psychology,  from  physics  to  management,  from  metallurgy  to  political 
sciences. 

In  a  typical  programming  session  at  a  terminal,  the  user  first  logs  in, 
giving  his  identification.  He  can  then  type  in  a  subroutine,  perhaps  usin 
the  MAD  language,  and  then  call  for  a  printout  of  his  input,  edit  it  to 
correct  errors,  and  call  for  a  MAD  compilation.  The  resulting  binary 
program,  possibly  with  other  programs  previously  compiled,  can  then  b 
loaded  and  executed.  If  the  run  is  unsuccessful  the  user  can  request 
post-mortem  data  to  assist  in  locating  the  fault.  If  necessary  he  may 
request  the  source  program  and  recompile  it,  perhaps  repeating  this 
several  times.  To  terminate  the  session  the  user  logs  out,  at  which  tiir 
he  receives  from  the  supervisory  program  accounting  data  indicating  ho' 
much  actual  computer  time  he  has  used.  Users’  programs  and  data  are 


stored  in  the  disc  files  of  the  system,  together  with  compilers  and 
other  public  programs.  Thus,  a  user  can  interrupt  his  work  when  he 
wishes,  and  start  again  where  he  left  off  at  his  next  session  at  a  system 
terminal,  hours  or  weeks  later. 

The  equipment  configuration  of  the  MAC  computer  installation  is  illus¬ 
trated  in  Fig.  1.  The  IBM  7094  central  processor  has  been  modified  to 
operate  with  two  banks  of  core  memory,  each  consisting  of  32K  words, 
and  to  provide  facilities  for  memory  protection  and  relocation.  These 
features,  together  with  an  interrupt  clock  and  a  special  operating  mode 
(in  which  input-output  operations  and  certain  other  instructions  result 
in  traps)  were  necessary  to  assure  successful  operation  of  independent 
programs  coexisting  in  core  memory.  One  of  the  memory  banks  is  avail¬ 
able  to  the  users*  programs;  the  other  is  reserved  for  the  supervisory 
program  of  the  time -sharing  system.  The  second  bank  was  added  to  avoid 
imposing  severe  memory  restrictions  on  users  because  of  the  large  super¬ 
visory  program,  and  to  permit  use  of  existing  utility  programs  (compilers, 
etc.)  many  of  which  require  all  or  most  of  a  memory  bank. 

The  basic  point  with  respect  to  the  MAC  system  in  particular,  and  time¬ 
sharing  in  general  is  that  as  a  strategy  for  imparting  to  a  computer  a  pro¬ 
gram  configuration  with  a  high  degree  of  generality  it  leaves  much  to  be 
desired.  The  construction  of  its  highly  efficient  and  comprehensive  super¬ 
visory  programs  merely  make  it  possible  for  more  than  one  user  to  have 
available  a  large  scale  conventional  computer  at  the  same  time.  But 
these  programs  do  not  contribute  at  all  in  making  that  computer  anything 
more  than  conventional.  Nor  does  the  time-sharing  strategy  make  avail¬ 
able  to  the  user  highly  sophisticated  problem  solving  techniques.  But  it 
was  never  intended  as  such.  Rather  it  is  a  responsive  design  strategy 
oriented  toward  providing  a  large  number  of  users  with  simultaneous 
access  to  a  large  scale  conventional  computer.  The  development  of  more 
sophisticated  user-on-line  techniques,  of  general  purpose  programming 
and  executive  routines,  of  problem-oriented  languages,  and  of  information 
processing  techniques  remain  as  problems  to  be  solved  within  a  multiple 
access,  time-shared  system. 

B.  THE  SDC  TIME -SHARING  PROGRAM 

The  SDC  time-sharing  program  is  similar  in  scope  to  Project  MAC  and  is 
designed  to  make  available  a  tape -oriented  AN/FSQ  32v  computer  to  10-15 
users  simultaneously,  each  of  whom  operates  independently  under  control 
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of  an  executive  system. 

The  executive  system  permanently  occupies  16,  384  words  of  core 
memory.  It  also  utilizes  around  6,  000  words  of  drum  and  about  9,  000 
words  of  disc  permanently  for  storage  of  additional  programs  and  data. 

Input  memory  is  used  by  the  system  for  buffering  between  the  PDP-1 
and  the  Q-32.  A  maintenance  program  (called  FIX)  occupies  an  additional 
2,000  words  of  core,  16,000  words  of  drum,  and  one  tape  drive  perman¬ 
ently.  Also,  the  remainder  of  the  drum  storage  is  utilized  for  storage  of 
active  object  programs,  and  thus  is  not  available  for  data  use  by  object 
programs.  The  remainder  of  the  computer  (core,  disc,  tapes)  is  essen¬ 
tially  available  for  the  object  program's  use. 

The  scheduling  algorithm  maintains  two  queues,  one  for  short  compute, 
highly  interactive  users  (determined  empirically).  These  users  operate 
in  an  essentially  round-robin  fashion,  getting  400  ms,  maximum  per  turn. 
Since  the  probability  of  more  than  one  of  these  users  requiring  compu¬ 
tation  at  the  same  time  is  quite  small,  these  users  generally  get  almost 
instantaneous  response.  The  second  queue  is  composed  of  users  who 
have  long  compute  requirements.  They  operate  with  a  much  longer  basic 
turn,  each  one  being  interrupted  only  by  the  occasional  requirements  of 
the  other  queue  of  users,  thus  making  the  amount  of  swap  time  required 
fairly  minimal.  Of  the  11,000  executive  instructions,  the  scheduler 
requires  only  500  of  these.  (The  remainder  of  the  executive  program’s 
space  is  occupied  by  data. ) 

The  programming  languages  available  are  JOVIAL,  IPL-V,  LISP,  SLIP, 
and  machine  language.  The  RAND  Ta  blet  is  now  part  of  the  hardware 
complex. 

The  difficulties  involved  in  the  development  of  the  time- sharing  system 
have  been  primarily  due  to  the  constantly  changing  hardware  and  software 
requirements.  Both  the  program  and  hardware  have  maintained  a  steady 
rate  of  change  since  the  beginning  of  the  system,  so  that  although  in  general, 
schedules  have  been  met,  and  use  of  the  system  has  been  quite  productive, 
numerous  problems  have  required  a  fairly  constant  work  force  a.id  level 
of  activity.  Since  this  has  been  an  experimental  as  well  as  productive 
environment,  this  situation  is  not  unexpected. 
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The  system  design  represents  two  major  and  relatively  distinct  efforts. 
First,  the  basic  executive,  described  above,  required  six  people 
(generally  quite  experienced)  ever  since  the  early  design  phase  in  1962. 
The  system  was  operational  eighteen  months  later  and  has  evolved  ever 
since,  requiring  roughly  the  same  level  of  six  people.  In  addition  to 
this  basic  executive,  a  large  number  of  "service"  routines  have  been 
programmed  and  made  available  to  both  programmer  and  non-programmt 
users.  These  include  compilers,  editing  routines,  interpreters,  aids 
to  calculation,  and  other  useful  routines.  In  general,  each  one  of  these 
routines  required  one  or  two  people.  The  time-sharing  project  has  j 
averaged  around  six  or  seven  people  on  this  kind  of  work  for  two  years. 


Figure  2. 


C1LARAC TE RISTICS  OF  EQUIPMENT  IN  THE  SYSTEM 
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Figure  2.  (CONTINUED) 
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Data  terminal  unit  I  m»hm 


PART  VI.  GENERALIZED  DATA  MANAGEMENT  SYSTEMS 


In  this  section  two  systems  are  discussed  which  represent  an  approach 
to  software  development  that  can  best  be  described  as  generalizations 
of  the  preceding  points  of  view.  These  two  systems,  ADAM  and  LUCID, 
have  attempted  to  construct  within  the  confines  of  one  computer  system 
environment  programs  which  incorporate  the  sophistication  and  power  of 
general  purpose  executive  routines,  the  job  specific  concentration 
exhibited  by  the  functional  systems,  the  flexibility  and  power  of  user-on¬ 
line  systems,  the  narrow  band  specificity  of  problem  oriented  languages 
and,  to  a  lesser  extent,  the  special  sense  of  generality  implied  by  time¬ 
sharing.  The  motivation  behind  this  undertaking  is  the  necessity  for 
devising  a  computer  based  system  which  exhibits  the  kind  of  flex;bility 
required  of  an  engineering  tool.  In  this  case  the  goal  of  the  engineer 
is  the  design  of  large  scale  computer-based  systems.  Hitherto,  he  has 
been  without  the  requisite  tool  to  facilitate  his  design  task.  ADAM  and 
LUCID  are  attempts  to  fill  this  gap. 

A.  ADAM  (ADVANCED  DATA  MANAGEMENT) 

ADAM  (Advanced  Data  Management)  is  a  current  effort  by  the  MITRE 
Corporation  to  develop  a  system  of  generalized  programs  which  antici¬ 
pate  most  of  the  features  of  an  on-line,  real  time  multi-access  informa¬ 
tion  processing  system.  The  purpose  of  ADAM  is  to  facilitate  the  rapid 
and  economic  conversion  of  an  IBM  7030  computer  and  its  peripheral 
typewriters  and  displays  from  one  alternative  system  configuration  to 
another.  This  capability  permits  alternative  design  decisions  to  be 
tested  and  verified,  e.  g.  ,  utility  of  graphical  input  capability  or 
adequacy  of  a  query  language,  by  the  experimenter  without  incurring  the 
usual  reprogramming  costs  associated  with  making  modifications  to 
conventional  computer  programs. 

The  essential  feature  of  ADAM  is  its  generalized  implementation  of  data 
management  functions  which  are  considered  to  be  common  housekeeping 
functions  in  most  systems,  i.  e.  : 
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(1)  Data  Base  Creation 

(2)  Data  Base  Alteration 

(3)  Data  Base  Augmentation  and  Reduction 

(4)  Data  Base  Regrouping 

(5)  Data  Base  Searching 

(6}  Data  Base  Analysis 

(7)  Input  Message  Analyses 

(8)  Output  Message  Creation 

(9)  Information  Formating 

(10)  Report  Generation 

(11)  Display  Generation 

(12)  Information  Routing 

(13)  Event  Sequencing 

(14)  Process  Implementation 


In  ADAM,  generalized  programs  for  implementing  these  functions  are 
written  without  explicit  reference  to  data- attribut  es,  message  format, 
display  makeup,  query  language,  etc.  ,  which  are  considered  the 
"specifics"  of  the  application.  Variation  in  data  base  organization,  qi 
language  syntax,  sequence  parameter  representation,  etc.  ,  can  be 
controlled  by  the  experimenter. 


The  operating  ADAM  system  accepts  messages  from  and  sends  output 
on-line  input-cvtput  devices,  such  as  typewriters,  display  consoles, 
printers  and  magnetic  tapes.  Messages  may  query  the  data  contained 
ADAM;  add,  change,  or  delete  data;  add  or  delete  programs;  or  cause 
operation  of  programs  which  have  been  previously  added.  Data  or  pr 
grams  added  to  the  system  become  part  of  the  system,  to  be  written  < 
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the  next  system  tape  and  remain  part  of  the  system  until  replaced  or 
deleted. 


Data  in  ADAM  are  contained  in  ADAM  files,  and  t ne  creation,  mainten¬ 
ance,  processing,  and  querying  of  the  files  ai  e  the  major  purposes  of  the 
system.  In  addition  to  files  of  problem  data,  the  system  contains  a 
file  of  routines  (both  system  routines  and  problem-specific  routines), 
a  file  of  languages  in  which  messages  may  be  stated,  a  file  of  formats 
for  outputs,  and  other  special  purpose  files. 

Operations  basic  to  the  use  of  ADAM  may  be  broadly  classed  into: 


File  Generation 


Creation  of  new  files. 


File  Processing 


Queries,  modifications  to  existing  files, 
computations  on  file  data. 


Problem -Specific 
Processes 


Program  Preparation 


Operation  of  7030  programs  (for  file 
manipulation  or  calculation)  which  are 
specific  to  a  problem  as  opposed  to 
general-purpose  constituents  of  ADAM. 

Compilation  or  assembly  of  7030  programs 
for  use  within  ADAM  and  their  insertion 
into  the  system. 


File  Generation,  Processing,  and  Problem-Specific  operations  all  result 
from  message  inputs  through  on-line  input  devices  or  the  MCPHnput  tape. 
Program  Preparation  requires  compilation  of  programs  off-line  by  the 
pre-processors  or  post-processors  followed  by  on-line  additions  to  the 
routine  file. 


New  input  languages  or  modifications  to  languages  may  be  made  through 
off-line  assembly  by  the  Language  Assembly  Program  followed  by  on-line 
additions  to  the  language  file. 

1.  File  Generation 

The  heart  of  ADAM  data  management  is  the  ADAM  file  and  the  rolls  corres 
ponding  to  each  file.  All  data  objects,  language  specifications,  routines, 
formats,  etc.  ,  are  carried  in  files.  A  file  is  a  named  collection  of  like 

*ADAM  operates  in  conjunction  with  the  Master  Control  Program  (MCP) 
for  the  IBM  7030. 
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things.  For  example  the  "airfield"  file  would  contain  information  about 
several  specific  airfields.  Each  airfield,  e.  g.  ,  Logan,  Hanscom,  etc., 
would  be  an  object  in  the  airfield  file.  The  various  data  about  each 
object  are  called  properties.  Typical  properties  for  the  airfield  file 
would  be  Location,  Number  of  Runways,  Elevation,  etc.  The  actual 
data  in  a  file  are  the  values  of  these  properties,  e.  g.  ,  Boston,  6,  2,  0 

feet,  etc.  The  set  of  properties  for  an  object  in  a  file  must  be  the  sam< 
set  as  for  all  other  objects  in  that  file.  Of  course,  the  values  of  these 
properties  may  change  from  object  to  object.  The  set  of  all  property 
values  for  one  object  in  a  file  is  called  an  entry  in  that  file.  ADAM 
files  are  structured  serially  by  entry,  the  first  entry  being  the  values 
of  the  properties  that  occur  once  per  file,  e.  g.  ,  file  name,  file  size, 
date  updated,  etc. 

A  roll  is  a  type  of  dictionary  or  directory  that  associates  external  name 
with  their  more  concise  internal  representations,  usually  some  small 
integer.  This  integer  is  called  the  principal  value  of  the  name.  Synony 
for  external  names  are  effected  by  a  many  to  one  mapping  of  names  to 
integers,  i.  e.  ,  all  synonymous  external  names  have  the  same  principal 
value.  Additionally,  a  roll  will  have  subsidiary  values  which  give  addi- 
tional  information  about  the  things  named  in  the  roll.  Within  a  roll, 
principal  values  are  unique. 

Each  file  has  associated  with  it,  but  physically  separate,  an  object  roll 
and  a  property  roll.  The  object  roll  contains  the  names  and  principal 
values  of  each  object  in  the  file  and  subvalues  which  give  the  objects 
location  in  that  file.  The  property  roll  has  the  names  and  principal  val' 
of  the  properties  in  the  file,  and  for  each  property,  several  subvalues 
giving  type,  size,  unit  of  measure,  location,  legal  range  of  values,  etc 
Files  may  also  use  rolls  to  hold  the  alphanumeric  values  of  some  of  the 
file  properties  (e.  g.  ,  red,  green,  up,  north,  or  some  other  non-numei 
value)  and  carry  only  the  principal  values  of  these  values  in  the  file  its* 
Many  files  may  share  such  a  roll.  Rolls  are  not  used  only  by  files;  the 
system  keeps  several  rolls  for  its  own  internal  use. 

Property  types  are  fixed-length  (integer,  floating,  small-range  or  low 
precision  floating,  or  alphanumeric)  and  variable -length.  Examples  of 
the  latter  are  query-valued  (some  processing  is  invoked  to  produce  the 
value),  raw  (arbitrary  string  of  bits  such  as  an  actual  alphanumeric 
string  as  opposed  to  a  principal  value  standing  for  such  a  string),  and 
repeating-group.  A  property  of  the  repeating-group  type  is  simply  a 
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collection  of  sub-properties,  which  may  themselves  be  of  repeating-group 
type  nested  to  arbitrary  depth. 

Any  data  amenable  to  structuring  may  be  introduced  into  ADAM.  New  files 
may  be  generated  from  external  data,  existing  ADAM  files,  or  both. 

2.  Queries  and  File  Processing 

The  principal  feature  of  ADAM  which  it  shares  with  no  other  generalized 
data  management  system  is  its  translator. 

The  translator  translates  a  message  in  accordance  with  a  language,  selecte- 
from  a  number  of  languages  contained  in  the  language  file.  The  selection 
is  based  on  a  language  specification  determined  by  the  recognition  rules. 
Translation  involves  transforming  the  syntax  of  the  message  into  a 
specification  of  operations  to  be  performed  and  transforming  the  names 
of  files,  etc.  ,  in  the  message  from  their  external  form  to  a  condensed 
internal  representation.  Translation  of  the  syntax  occurs  with  reference 
to  the  specified  language.  Translation  of  names  requires  directories  of 
names  or  rolls  and  are  used  as  required  by  the  translator.  The  trans¬ 
lated  message  becomes  a  process  table,  which  is  a  set  of  pseudo  instruc- 
tions  which  specify  various  subroutines  that  effect  the  processing  specified 
by  the  message.  The  process  table  may  call  for  combinations  of  file 
processing  and  problem  programs  in  essentially  any  order.  The  processor 
interprets  the  process  table  by  examining  each  pseudo  instruction  in 
order  and  calling  upon  the  appropriate  subroutines  to  perform  the  action. 

This  function  of  the  ADAM  system  permits  several  potential  users  to 
specify  the  syntax  of  a  query  language  relevant  to  their  own  problem  area. 
The  sentences  generated  by  each  of  their  respective  grammars,  however, 
will  be  acceptable  to  the  ADAM  translator  without  the  necessity  for  its 
being  reprogrammed.  In  different  words,  the  ADAM  translator  is  a  syntax 
driven  compiler  which  provides  the  same  translation  capability  to  any 
number  of  different  users  without  reprogramming.  Thus,  the  ADAM 
translator  may  also  be  viewed  as  a  query-language  modelling  facility  which 
allows  for  the  study  of  query  languages  without  building  software  prototype! 
Such  facilities  as  these  exemplify  what  is  general  in  generalized  data 
management  systems. 
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3. 


Routines 


An  ADAM  routine  is  a  piece  of  code  which  obeys  ADAM  rules  for  commi 
eating  between  routines  and  data.  Routines  are  prepared  in  DAMSEL 
(a  procedural  language  available  in  ADAM)  or  FORTRAN.  In  either 
case,  some  off-line  processing  is  required  to  produce  a  binary  form  of  t 
routine  with  its  communication  information  included.  This  binary  routin 
is  what  is  then  inserted  into  the  ADAM  system.  Theoretically,  routines 
and  their  communication  links  may  be  directly  prepared  also  via  the 
SMAC  and  STRAP  assemblers.  Routines  are  all  relocatable  and  are 
size  limited  only  by  the  amount  of  available  core  when  they  are  to  run. 
All  ADAM  routines  are  kept  in  a  special  file  called  the  "routine  file.  " 

4.  System  Control 

The  system  control  philosophy  of  ADAM  is  to  accept  input  messages  as 
they  arrive,  recognize  them,  and  place  them  according  to  some  priority 
scheme  in  a  job  queue.  An  ADAM  message  is  any  string  of  characters 
from  an  input  device  that  ADAM  can  recognize.  ADAM  will  recognize  a; 
input  language  whose  recognition  rules  are  given  to  the  system.  When 
a  running  job  is  completed,  the  top  of  the  job  queue  is  examined  and 
the  appropriate  routine  is  called  (problem  program,  translator,  query 
analyzer,  etc.)  and  enjoined.  When  the  job  is  started,  it  runs  to  comple 
tion,  being  interrupted  only  for  recognition  and  stacking  of  input  messag 
This  implies  that  only  one  program  (other  than  utility  routines)  can  have 
the  machine  at  one  time.  The  amount  of  multi-programmii  g  of  user 
programs  is  minimal.  Requests  for  output  are  handled  immediately  if 
the  channel  and  peripheral  gear  are  available;  otherwise,  they  are  queut 
up  and  sent  out  when  possible.  All  system  routines  (input/output  hand¬ 
ling,  job  scheduling,  memory  allocation,  etc.)  are  subroutines  and  may 
call  each  other  as  needed. 

Streams  are  an  artifice  whereby  any  ADAM  data  structure  can  be  con¬ 
sidered  of  arbitrary  size,  existing  over  more  than  one  storage  media 
(e.  g.  ,  part  in  core,  overflowing  onto  disk).  Two  routines  are  provided 
for  the  handling  of  streams.  Other  control  routines  available  auto¬ 
matically  to  the  system  are  a  disk  and  tape  allocator,  core  allocator, 
routine  loader,  and  roll  controller. 

Thus,  ADAM  is  a  system  which  performs  data  management  functions  by 
general  techniques  independent  of  the  form  of  data  or  calculations  requij 
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in  any  specific  application.  ADAM  treats  as  data  the  specifications  of 
a  specific  system  design.  Through  its  operator  language,  designers 
are  able  to  dynamically  modify  system  specifications  resulting  in  a 
convenient  evolution  in  design.  Furthermore,  because  the  designer  has 
access  to  current  system  specifications  in  ADAM,  ADAM  itself  can  be 
used  to  prepare  reports  on  the  design  and  can  generate  on-line  displays 
for  assisting  users  to  both  use  and  modify  the  system. 

B.  LANGUAGE  USED  TO  COMMUNICATE  INFORMATION  SYSTEM 
DESIGN  (LUCID) 

LUCID  is  a  user-oriented  language  and  macro  system  for  the  design  and 
evaluation  of  data  retrieval  and  manipulation  systems  in  a  laboratory 
environment.  The  system  is  being  written  for  the  AN/FSQ-32  computer 
at  the  System  Development  Corporation,  Santa  Monica,  California.  The 
objectives  of  this  system  are  to  provide  the  information  system  designer 
with  an  integrated  set  of  closed  JOVIAL  procedures  and  a  convenient 
means  for  arranging  them  in  appropriate  complex  hierarchies  under  a 
control  program  to  provide  data  base  maintenance  and  on-line  data-base 
query  capabilities. 

The  LUCID  system  is  designed  to  operate  from  a  Master  Tape.  In  the 
Phase  I  version  of  the  system  there  are  four  system  files  on  the  Master 
Tape.  These  files,  (1)  System  Control,  (2)  LUCID  Translator,  (3)  On- 
Line  Query  System,  and  (4)  Interpreter,  contain  not  only  the  appropriate 
LUCID  system  routines  for  performing  designated  functions,  but  in 
addition,  they  contain  tables  which  are  a  complete  parametric  description 
of  the  user’s  system  under  investigation.  Because  LUCID  programs  are 
highly  generalized,  they  must  be  supplied  with  certain  parameters  by  the 
computer  center  staff  even  before  the  system  can  be  employed  as  a 
design  tool.  Thus,  the  System  Control  program  provides  an  initial 
parameter  load  capability  which  specifies  input  media,  output  media, 
available  tapes,  symbolic  representations  of  LUCID  operations,  comments 
to  be  communicated  to  the  designer,  etc.  Once  the  system  is  initialized, 
experimental  file  structures,  input  data,  temporary  files  and  processes 
for  the  manipulation  of  the  data  can  be  easily  described  in  the  LUCID 
language  by  the  experimenter.  These  descriptions  are  translated  by  the 
LUCID  translator  into  binary  tabular  form  called  OPAQUE.  The  OPAQUE 
tables  are  then  examined  by  the  Interpreter  which  calls  in  the  necessary 
macro  routines  for  building  and  processing  files,  thus  implementing  a 
specific  system  design. 
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The  most  salient  characteristic  of  the  internal  structure  and  design 
philosophy  of  the  LUCID  system  is  the  number  of  tables  used.  In  addi¬ 
tion  to  the  OPAQUE  tables,  others  such  as  communication  tables,  con¬ 
trol  tables,  temporary  storage  tables,  and  a  table  of  operators  are 
generated  automatically  by  the  system. 

LUCID  admits  six  levels  of  data  structure:  data  base,  file,  table 
entry,  item,  and  bead.  Four  structures  of  data  tables  (linked,  serial, 
parallel,  and  mixed}  can  also  be  accepted  by  the  system.  A  linked 
table,  hot  accessible  to  the  user  in  the  present  system,  is  a  table  in 
which  each  entry  provides  the  index  for  the  next  entry.  Serial  tables 
are  serial  by  row  and  parallel  tables  are  serial  by  column.  The  mixed 
table  consist  of  two  parts,  a  fixed-entry-length  part  and  a  variable - 
entry-length  part.  Each  fixed-entry  component  contains  a  cross  refer¬ 
ence  to  the  variable -entry  part. 

LUCID  also  has  provisions  for  the  generation  and  maintenance  of  a  con¬ 
cordance  of  the  data  base  which  is,  in  effect,  a  copy  of  the  data  base 
with  the  contents  listed  in  a  different  way.  Some  but  not  necessarily 
all  of  the  property  values  are  used  in  a  normal  manner.  The  size  of 
the  conco-dance  varies  from  slightly  smaller  than  to  three  or  four 
times  the  size  of  the  data  base.  This  type  of  organization  facilitates 
certain  retrieval  operations,  but  can  be  very  inefficient. 

Current  capabilities  include  off-line  file  generation  and  system  de¬ 
scription  with  card-to-tape,  tape-to-card  being  the  conventional  input/ 
output  mode  of  operation. 
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CONCLUSIONS 


From  this  survey  on  important  perspectives  in  advanced  software 
development,  it  is  apparent  that  several  new  and  powerful  entries  have 
been  made  in  the  roster  of  software  innovations.  Thus,  the  general 
purpose  programming  and  executive  systems  cited  in  this  survey  have 
contributed  significantly  to  the  notion  of  the  "extensible"  machine  where 
storage  allocation,  program  linkage,  program  segmentation,  sequence 
control,  error  detection  and  correction  and  I/O  control  capabilities 
are  provided  as  tools  for  building,  controlling  and  modifying  programs. 
Functional  systems  such  as  COLINGO,  NAVCOSSACT,  FICEUR  and 
473L  have  incorporated  new  techniques  for  retrieving  data  from  large 
numbers  of  formatted  files  and  for  manipulating  these  files  in  an  effi¬ 
cient  manner.  In  the  area  of  man-machine  interface  techniques, 
SKETCHPAD,  CULLER-FRIED,  JOSS,  and  BASEBALL  have  each 
contributed  new  ways  for  non-programmers  to  interact  with  computers 
through  the  development  of  graphical  manipulation,  calculation  and 
natural  English  accessing  capabilities,  respectively.  Similarly,  COGO 
and  STRESS  have  shown  where  languages  tailored  to  specific  problem 
classes  promise  an  order  of  magnitude  improvement  in  the  problem 
solving  ability  of  non-computer  specialists.  Finally,  generalized  pro¬ 
gramming  techniques  in  the  form  of  data  management  systems  promise 
significant  improvement  in  the  flexibility  of  multi-user,  on-line,  com¬ 
puter-based  systems. 

The  desirable  features  found  in  all  of  these  systems  are  summarized 
below: 

(1)  Addressing  the  computer  in  a  specific  problem  area  (COGO, 
Sketchpad,  etc.  ) 

(2)  On-line  users  controlling  their  computational  processes. 

(3)  Referencing  data  objects  by  name. 

(4)  Description  of  data  objects  independently  of  the  program 
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(5)  Use  of  programming  and  retrieval  languages. 

(6)  File  maintenance  procedures. 

(7)  Scheduling  and  monitoring  functions. 

(8)  Creation,  modification  and  evaluation  (running)  of  programs 
and  data. 

(9)  Time  and  facility  sharing. 

(10)  j  Automatic  allocation  of  machine  resources. 

(11)  Specification  of  parallel  paths  of  processing. 

(12)  Extensibility  into  various  problem  areas. 

All  of  these  features  contribute  to  more  effective  use  of  computers  and 
may  certainly  all  be  present  within  a  given  system.  Indeed,  many  of 
these  features  exist  at  varying  levels  of  use  and  sophistication  in  many 
of  the  systems  that  have  been  examined.  For  example,  both  COGO  and 
ADAM  have  an  executive  control;  one  is  primitive  and  special-purpose, 
other  quite  sophisticated  and  general.  It  is  also  true  that  the  various 
features  are  achieved  at  different  costs  in  different  systems,  e.  g.  ,  it 
would  be  cheaper  to  include  an  ALGOL  translator  under  the  CL-II  systei 
than  it  would  be  under  COLINGO  . 

I 

Given  that  the  features  in  the  above  list  have  proved  to  be  valuable, 
individually  and  in  various  combinations,  the  approach  of  the  designer 
of  "next  generation"  systems  might  profitably  be  the  following:  rather 
than  concentrating  on  a  specific  application,  and  building  up  from  scratc 
a  computer  system  to  meet  those  requirements,  he  should  start  by 
designing  a  hardware  -  software  sub-system  which  provides,  or  facili¬ 
tates  the  provision  of  all  (or  a  large  subset)  of  these  desirable  modes  of 
operation,  programming  environments,  etc.  If  this  can  be  done  in  a 
very  general,  and  reasonably  efficient,  fashion,  the  designer  will  have 
at  hand  the  beginnings  of  any  number  of  different  systems,  each  of  whicl 
will  be  relatively  easy  to  modify  and  expand,  as  requirements  dictate. 

In  the  light  of  this  observation,  it  is  important  to  note  that  to  date  effort 
to  develop  generalized  systems  and  sub-systems  exist  only  on  a  very 
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small  scale  and  in  only  a  small  number  of  laboratories  scattered 
across  the  country.  As  a  consequence,  there  does  not  now  exist  a 
single  system  in  which  all  or  many  of  the  techniques  mentioned  above 
are  being  integrated  into  one  efficient  configuration.  And  this  is  in 
spite  of  the  fact  that  computer  systems  so  designed  would  be  opera¬ 
tional  tools  of  inestimable  value  to  the  military  in  general,  and  to  the 
Air  Force  specifically. 

And  this  brings  us  to  the  final  observation  of  this  survey:  namely,  the 
time  is  now  ripe  for  a  technical  program  designed  to  demonstrate  the 
feasibility  of  generalized  computer  systems  and  sub-systems  in  the 
solving  of  traditional  data  processing  problems. 
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